Okay, welcome to the session on JBuilder 5 for Mac OS X. So, many of you have seen me before in one session or another. My name is Blake Stone, Chief Scientist for Borland Software Corporation. We dumped the in-prize moniker for good. Yes. And we'll be spending a lot of time looking at a lot of detailed features in JBuilder. You've probably seen some quick overview views.

You've seen a smattering of features, but not a lot of explanation for what's behind them, and no look really at what's new in JBuilder 5, especially since JBuilder is really new to the Macintosh community as a whole at this point. But I know there's some of you out there who are already JBuilder users and are just waiting, so we'll showcase some of the JBuilder 5 new features as well. Blake Stone Why don't we have a look, in fact, at what we're going to do.

With the tour of JBuilder 5, we're going to try to walk through the major areas, but it's a big, deep product. Anybody who's used it knows that. I'll try to give you a hint of what's there, but if you don't see something you're interested in, get a hold of us.

Get on the news group, check out the CD we've handed out, whatever it takes. Make sure that you find out the answer to your question. And of course, I'll be hovering around the conference for the next day or two as well. Blake Stone We're going to cover some of the new features.

We're going to look at the new features in JBuilder 5, and we're going to look a little bit at writing Macintosh-specific code in JBuilder, because we keep talking about pure Java and how JBuilder is pure Java, and some people confuse that with being swing-specific. Java is Java. You can as easily write Cocoa applications in Java, with a few caveats we'll talk about in a little bit, as you can write swing applications, and so that's an interesting topic by itself.

We'll talk a little bit about the preview CD you got and how to get that up and running to the best of its ability, especially getting a hold of the new features. Blake Stone We'll get a hold of the update that you require to the VM from Apple to really make it sing, and then we'll have a Q&A session.

So JBuilder, the basics that we're going to walk through. You'll see everything, of course, uses the Aqua look and feel. And this is courtesy more of Apple's work than anything we've done. We've tried to make sure that we use Swing purely for all of our user interface. And so the Aqua look and feel does a great job of translating our appearance into a really nice Macintosh user experience.

Blake Stone So JBuilder, the basics that we're going to walk through. You'll see everything, of course, uses the Aqua look and feel. And this is courtesy more of Apple's work than anything we've done. And so the Aqua look and feel does a great job of translating our appearance into a really nice Macintosh user experience.

Blake Stone So JBuilder focuses very much on allowing you to keep directly in touch with your source code. It differs from some of the other major tools out there in that not only do we get direct access to your source code and you spend a lot of time on it, but it also allows you to keep in touch with your source code.

code and you spend a lot of time in the editor manipulating code, but we store your source code in just standard files. There's no binary repository anywhere that hides your code from you so you can very easily use JBuilder in conjunction with other tools that expect you to have direct access to your code. We're going to talk a little bit about the performance of the editor because that's something that I think is an interesting topic for Java developers.

Everybody was told from day one Java is slow. Java is slow. You hear it often enough and you begin to believe it. But the actual fact is that Java code is amazingly quick. Hotspot is a startling technology and can do a lot of things in a dynamic compiler that you can't even do in a static compiler. So we wring a lot of performance out of it and you'll see a lot of that in the editor.

The editor does some interesting structural analysis that if you were at the Java developer tool session we talked about a little bit. And of course we added something to the editor to make it comfortable for you. We added key bindings that mirror the text edit, project builder, sort of the standard class editor. They're sort of the standard classical Apple key bindings as well as the BB edit slash code warrior key bindings that you may be accustomed to so you don't have to retrain your fingers for a whole new set of keystrokes.

We're also going to talk a little bit about navigation through your source code, code insight and Java doc and how they increase your productivity right from day one. And this is going to be kind of an ongoing theme, this increased productivity. How do we make you more productive each and every day in the product rather than how do we provide some things that we don't want to be able to do? So you may be able to do a lot of things that look good in a demo and may help you learn on the first few days but then you grow beyond them.

No, no, no, these are tools that you will use again and again and again as you continue to develop Java code. We're going to go from there into a little bit more about the project orientation of JBuilder, the fact that the project structure isn't something you need to spend a lot of time fiddling with in JBuilder.

There are a lot of other products where you need to add every single source file. Well, we deal with projects of thousands of source files and so if adding and removing them from your project is not the right thing to do, then it is. We're going to be able to do that in a little bit more detail in a little bit more detail. But if you're going to do a lot of work in a project that is a major maintenance nightmare, that's something we need to get rid of. And in fact, we've done some very interesting work on that area.

We've got a very fast compiler. You'll see that every single demo I do, of course, the compiler will kick in with very clever dependency checking. We'll talk a little bit about that. And a very powerful archive builder. So if your project construction process involves producing a jar for someone, we can help you out there too. So let's have a look at those very basic characteristics of JBuilder.

If we can flip to the system in front of me here, we'll go ahead and bring JBuilder up. see how well the optical mouse tracks on this lovely surface. And JBuilder is structured so that you can see a number of things at once. And I might as well introduce them before we get a little bit deeper.

The project view in the upper left-hand corner here is where you see the structure of your project, the packages that comprise your project, your source files. The lower left is where you see structural information, and the center is where you see the content view, where we can open any number of files concurrently. So I've got, in this case, Welcome app and Welcome frame open, which we can flip back and forth between.

Along the bottom of the content view, we have a number of different viewers for that particular content. And we'll see some of those a little bit later. But just so you know what's where and why I'm doing the things I'm doing. We focus on the editor a lot of the time.

So the editor had better be fast. It had better just keep up with my typing as fast as I can type. It had better scroll quickly through my code, so I'm not waiting for it a lot. And that's not all that impressive until you realize that every single line of code-- every single line of code in JBuilder is written in Java. So your applications can look this fast, have this kind of response and performance.

So if you were concerned about Java from that standpoint, please don't be. Also, we do a lot of structural analysis on the code. So as I type slash and I'm about to hit a star, you'll notice that we can immediately note that all of that is a comment, there is no structure, we've colored it green, and just as quickly, it comes back. So very, very quick analysis.

And we talked about this a little bit in another session, just in case you weren't there. And out of interest, how many people here weren't at the developer tools session for Java earlier today? OK, a number of you out there. So if you were, please forgive me. We'll try not to dwell a lot on things that were talked about there.

But the structure over here shows me the structure of the class I'm working with. And so if I declare a new integer, it shows up in that structural view. We can actually control how quickly these things are updated, and we've got it set about as fast as it'll go. So as I continue to type, you can see that on the fly, in real time, we're able to discover that this variable name is changing over here.

So that gives us the ability really to give you a constant heads up about the state of your file. Because not only can we show you the class and its members and give you a quick navigational interface, we can also show you if you make a mistake, like omitting a closed brace here, that there are structural errors in your code immediately.

So that you know what's going on. You can find out what's going on. And you can see that there is no catch associated with this try because we never closed the try block. And just that fast we can correct it without ever going through a compile cycle. So that's a really important piece of getting you performant in the environment. By the way, as far as the editor goes, again, for those of you who weren't here, it's very fully featured.

So I can do things like block, indent, and unindent no problem, comment out a set of lines, a whole bunch of very helpful keystrokes, and a bunch of quick mechanisms for typing common structures. Like if I want to put an if block in place, I can put an if else block and expand that template with just a couple of keystrokes.

All of these things are customizable for your preferred key bindings. So I can easily go in and say, I'd like to customize a key binding and change the keystrokes, or even just go in and use one of the prefab ones like my Macintosh or Macintosh Code Warrior key bindings.

And I'm going to accept all of the defaults here for an untitled project, but I'm going to tell it that I already have source code for this project in another location. Specifically, I'm going to go look at the samples we provide and pick up the chess sample source.

So if I go ahead and build this project, immediately my project pane shows me that these are the packages I have. They're sub-packages and all of the source files. I don't need to define this by hand. And in fact, if I were to go and check code out of a repository into that directory, I can easily refresh and get the up-to-date information. Or next time I open the project, it'd just be there without my having to ask for it. So very powerful tool. Now all I need to do to build this project is request a compile, and the compiler kicks in.

It's interesting, we're not getting a whole bunch of build progress reported. Of course, I am working with an interim build of the Java VM here, so heaven knows what we'll run into, the usual demo gremlins. But as you saw there, it didn't take very long. It's hard to believe it did anything at all, but in fact, it just produced class files for every single source in here. And as you saw a moment ago, there's a number of packages and sub-packages, and everything was compiled.

Subsequent compiles are amazingly quick as well. If I go into a particular file, and we'll just mark it dirty by making a change to it, and then go ahead and say recompile this project, then it notices very quickly there's only one file that needs to be recompiled. But it's not like your typical system where if I'd made a change in the API that somebody else required, it would just be broken. No, no. If I make a change that somebody else is going to call, then it notices that not only does this file need to be compiled, but, eh, turns out it's not going to be compiled. that's API nobody else uses.

Wouldn't you know it? I don't know this particular demo real well. I love just sort of flying by the seat of my pants. It finds that in fact there's a reference to that method somewhere else and it tried to recompile all the files that required that piece of API.

So it's a very frighteningly complicated system, but in fact one that just takes care of all the grunge work for you. Blake Stone I work on a project that has thousands and thousands of source files. JBuilder. And I use JBuilder as my IDE and I can compile changes in a matter of seconds to this enormous project and it follows all of the dependencies for me and takes care of all of the details. So that's pretty amazing from my perspective. I'm not going to save my changes.

Blake Stone The next thing that I mentioned is that once I'm done building a project and I've got a bunch of files, I probably want to deliver that to someone. Blake Stone And so archive building is an important part of that. Blake Stone It's an important part of the compiler, the build process. So what we've got is a technology called the archive wizard.

All I do is go into the archive builder wizard here and say I'd like to build an application from this. I can set all sorts of options or accept defaults. I can come in at any later time to any of the jars that I'm trying to build and edit their characteristics.

In this case, I'd like to specify a particular class as the main class for this application. Blake Stone If I remember correctly, we'll go ahead and pick the server side of this particular chess app. And now when I go to recompile, it's going to recompile my files. Did I actually save that accidentally? That would be bad.

We'll go ahead and look for it. Yeah, I accidentally did. One of the things I'm using here, by the way, I'm just typing in a tree. And it brings up a little search mechanism that allows me to search the tree. It's kind of interesting because I can search based on wildcards and find all of the things that start with GE. Or say, I'd like to find the things that have PL somewhere in them and then move among those. It turns out to be only one. So let's go ahead and change this back. Apologies on that. So now it goes ahead and compiles and creates the archive.

So it's built a jar for me that contains all of my classes, that contains the manifest entries. And I can verify that by actually opening the jar in the product and having a look at its contents, including the manifest file. So really quick way of going ahead and dealing with projects, building output. It's not something you would expect from Java. But having built this over time, we've gained really a new appreciation for just how fast Java can be. If I can get back to my slides, please.

So I promised we would go through this at a fairly blistering pace. Please excuse me. I normally like interactive sessions, but there's just far too many people further back to make that really practical here, so we'll take Q&A at the end. Visual design is a big piece of the JBuilder environment because Java beans are a big piece of the set of Java specifications.

They were a very early player in the numerous Java specs that are out there now, but they're an important part of how we take a class-based language, because Java really understands classes and members at the lowest level, but doesn't have any component-based architecture at the language level, and layers on top of that a component architecture that understands properties and events.

So JBuilder understands the Java beans architecture and provides a very sophisticated designer. So you can take Java beans from anywhere, Java beans from Sun, like AWT and Swing, although I'd argue about Swing being acceptable Java beans occasionally, Java beans from Borland. And we provide a set of databases.

We have data access technologies and Data Express that really are layered over top of JDBC, DBSwing, which are data-aware Swing components, and Internet Beans, which allow you to produce dynamic HTML using a set of beans, or third-party components, because Java beans is a standard and we can drop any bean into the IDE, and we'll look at how easy that kind of thing is to do.

All of this is done using Borland's patented two-way tool technology, and two-way tools are what allow us to do visual manipulation of a file, and then go back and modify it. So you can go back and modify the source code and see those changes reflected dynamically in the graphical environment, so that you can seamlessly move back and forth. There's no code generated that you aren't allowed to touch. It's your code. So let's have a look at that. Again, back to the demo machine, please.

They're going to get sick of my saying that. They know they should switch back to the demo machine. So if we go into just a very simple application here, this Welcome app, and I go ahead and open the Welcome frame in the designer, what's going on now is we're having a look at the source code and figuring out what it looks like. And it looks like a very, very empty frame.

Blake Stone So that's fine. I can start with this as a starting point and say I'd like this frame to use an XY layout, which is sort of an absolute positioning technology. I'd like to put a button and a text field on it, and perhaps I'd like to put a scrolling area and a tree as well. Blake Stone And everything I'm doing here is generating source code. If you look at this JB init method, this is sort of my static construction of this environment. Blake Stone But I can do... Blake Stone Again, this manipulation of code or manipulation visually.

Either way, it's up to me. So if I don't like the text on that button, I want the text on that button to say add. And again, if you weren't there, I did a rather perverse little demonstration a moment ago in one of the other sessions. I actually put an expression in here.

Blake Stone Well, let's be even more obnoxious about this, and let's go between JButton1 and setText and add a comment. Blake Stone So we've got here a piece of logic. Blake Stone We've got a legal Java code that has changed the label on this button to add item. And if we flip back to the designer, the designer parses through that and says the button has the text add item in it. Nice stuff. Blake Stone It goes a step further.

Let's say I change that text to remove item. Well, it's got an expression and a comment and a bunch of other sort of nasty stuff in there. So if I make that change and go back to my source code, what happens? Well, we leave everything in your code the way it was and make a surgical change to replace only the expression that used to be there with the new value that you've typed in. So again, it's your source code. We just help you with it.

So what I've got here is I've got a fairly basic and relatively unattractive layout, but if you'll excuse me, I'll just sort of juggle that a little bit here. One of the important things about Java are layout managers. There are some slick technologies in Interface Builder for helping you position things, but you're still positioning them using absolute positioning.

What happens when I then translate my application into another language and the text on a button gets longer? Well, you need to come up with another set of absolute positions for that. Or what if I change my font size? Then everything needs to be arranged differently, and that's sort of difficult to deal with. Well, Java uses layout managers to cope with this, but layout managers can be tough to understand. There's one called grid bag layout that's the most powerful, perhaps, and it would allow me to do a lot of very sophisticated manipulation of this.

But I would need to know all about grid bag constraints. So instead, what we can do is we can use JBuilder to help me out here. So I'm going to lay things out the way I want them, and then go back and say, I don't want to use XY layout. What I want to do is use grid bag layout. And behind the scenes, what we've done is translate all of my calls with absolute positioning into grid bag constraints.

Some of you have obviously done some grid bag work before. So we can literally go through and resize this, and you'll see that we have inferred some rather reasonable resizing behaviors for this. So the designer is a pretty cool piece of technology, even if you think about it in terms of standard components.

But what if we want to write our own components? Has anybody here tried to add a component to Interface Builder's palette? The one or two. You know, the rest of you haven't tried it because you knew it was easy, right? I'm sorry to pick on it, but really it's an early component model where the important thing was being able to provide reusable components.

And for us, we decided that it was important to be able to create reusable components. So I'm going to create one right now. Thank you. So what I'm going to do is create a new class. And this particular class I'm going to call myButton, and it's going to descend from javax-swing-jbutton. So it's just a button at this point.

And we go ahead and generate some code. We have a look at it to see if you need to do anything in particular. And all I'm going to do in my button is go ahead and say, by default, I'm going to set the background on the button to the color green.

And if there are any people here who worked on the Aqua look and feel, they may be cringing at this moment. Is this a good build to do this in? We'll find out. So what I've done is I've created a new button here. And of course we actually need to import Java AWT.

to get access to color constants. So I've got a new button here. What if I go into my code and I want to use one of those? Well, for one thing, grid bag is not the friendliest place to manipulate things. So I'm going to go ahead-- although we do provide you a lot of hints about what the various insets are and so forth, and you can visually manipulate them. That's kind of nice. But I'm going to flip back to xy layout, so I can go ahead and use absolute positioning and bring my new bean in.

How hard is it? Well, you could add it to the palette using a couple of steps. But you could also just say, I'd like to use the Any Bean tool and just go out and find it. And so in this case, I have this com_borland-- we're still in samples, right? Welcome my button. So I can go and pick a new button that I've created and drop it in place. Green background setting was not a good choice. I take it. Let's go ahead and set the foreground color instead.

Let's change this to set foreground. I don't need to spell the whole thing. Code Insight will give me a hand there. Go ahead and compile that. and come back to welcome frame now you notice a couple of interesting things one I change the class on the fly and we picked up the new version of the class and injected into your existing a code here so you can do it or if development you don't need to shut down and restart or anything like that will just pick up new versions the being as fast as you can throw them at us but second you'll notice that we have a new being dropped in just like that now let's go one step further I could go zillions of steps further but this is a a limited session of course I'm gonna do a get foo method and a public void set foo method And I'm going to be really obnoxious and not do anything with the value. Perhaps GetFu will always return-- sorry. Go ahead and compile this. Flip back to my welcome frame.

Are we seeing just paint issues? And what we'll see is that the foo showed up in our inspector automatically. No work on my behalf. It notices that it's a string and gives you a string type editor for it. That's JavaBeans and the visual designer. There's some incredibly slick stuff that you can do here. I could get into database components, what have you. If we have enough time, we'll come back and we'll look at some of those things. But if we can return to the slides, we'll move on from visual design.

Java server pages and servlets. This is a big deal for a lot of people looking at Java for server-side development. It's a technology that's blessed by Sun as the standard way of doing dynamic content because, of course, in the web, static HTML is yesterday. That's not interesting anymore. What we want is content that's generated on the fly. And JBuilder provides some very interesting support for dynamic web content through Java server pages and servlets.

One of the things, of course, is that with JSPs, what you have is a mix of HTML and Java. Now, we wouldn't recommend that you embed a lot of Java in your HTML. Typically, what you're going to embed are references to significant other technology that you maintain elsewhere so that you don't have your presentation and your behavior too intermixed. But it still gives you the flexibility of choosing on a variety of interesting ways what content to call in dynamically into your static HTML.

It's just that we need a way to edit this stuff. Also, we need to be able to run it. So you could take that JSP page and set up a server and get the server running and open your web browser and view it, but it would be nice if we did something there, so we'll show you that. And, of course, all the way through to actually viewing it in an HTML viewer. JBuilder integrates this whole process, and we'll see how. There are a bunch of new things in JBuilder 5 that, if you're familiar with servlets and JSPs, might be of interest to you.

Support for multiple servlet contexts. This is one of them. Before, we supported a single servlet context, and that was sort of annoying if you needed to integrate several different servlets which had references to, quote, "absolute positions" within their context that conflicted with one another. If you integrated those into one project, things got confusing.

So now we allow you to separate those into two separate servlet contexts that have their own root level for the set of HTML references. It's also interesting to generate WAR files. Why? Before, JSPs and servlets were individual files that you sort of managed on your own. Now there's a new standard for web archives, WARS, that you want to be able to deploy a whole set of functionality in one go, and JBuilder will build your WAR for you.

Also, vaguely related, but, you know, didn't want to slide on its own, Web Start bundling. Did anybody here see the Web Start demo in the Java intro? A couple of people here. So Web Start is a neat way of delivering your application. What you can do is bundle it up with a web page with a bunch of things and a bunch of XML and, well, wouldn't it be nice if you didn't have to do that? Somebody else did it for you. And that's what JBuilder's here for.

We're also going to talk a little bit about Java debugging. I didn't want to do too many flips back and forth between the slides, so we'll have a look at this a little bit. Because if there's anything you spend perhaps as much time in as your source code editor, it's probably your debugger. I'll admit it, I don't write bug-free code the first pass, but by the time I'm done with it, it's in great shape because we provide you a lot of really powerful tools.

So we'll talk a little bit about the Java debugger. It's an integrated debugger in the IDE, and a couple of the things that it does that are really noteworthy, not only can you browse through objects and so forth, but we provide full expression evaluation. That means not only can I see the value of a variable, I can call a method on an object and see the return of that, or I can even modify it by calling a setter or something. So it's a very sophisticated debugger from that perspective.

And it provides you the ability to edit absolutely any data type. A lot of people will say, yeah, we can modify data types. We can modify data in ours, but they usually mean we can modify primitives, integers, and characters, and if you're really lucky, maybe strings. But in practice, we can actually edit just about any data type, which is pretty neat. It also has extremely flexible breakpoints. Everybody's used to seeing the click on a line and get a breakpoint, but we provide line breakpoints, class breakpoints.

That's kind of interesting. I want to know any time anybody calls any method in a given class. And you can use wildcards for the name of the class. So you could say any class with the letter E or something equal to E. That's basically silly. But there are times. Anything in this package, for example. Field access and field modification. If the underlying VM supports it, we allow you to provide breakpoints on modification and access to fields, which is pretty slick stuff.

That's similar in some ways to database breakpoints in traditional C debugger, except that we're able to say for any member or for any instance of this class, whenever this field is touched. So you don't need to try to track down where all of this is. And we can also provide breakpoints on exceptions. So you want to know, of course, I've got an exception handler for my IO exception, but I want to stop if an IO exception is actually thrown.

And we can do that with our debugger. Also, of course, once the debugger has a breakpoint defined, you want to be able to refine it further. Provide an expression that gets evaluated or provide a number of times through that it needs to go before it will actually break.

Or even provide an expression that gets logged and not have it stop at all. These are all features of the debugger that we have. So let's see both of these things. We'll go through some of the web technology and we'll go through a little bit of the debugging technology. So I'm going to start a brand new project to look at some of the web stuff.

And within this project, I'm going to create just an empty JSP. Nothing particularly fascinating here, but actually, yeah, let's go ahead and do that. So where's my project? And you'll see that, and actually let's add that to my project as well. It's probably something I shouldn't have done. By the way, a lot of you may have seen this file browser that comes up, and it's not the standard file browser. Why? We do some interesting things with it.

In Java, you need to be able to drill into some file types that you might not normally look into. For example, if I've got a jar, it would be sort of nice to be able to see the directories in the jar, the files in those individual directories inside the jar, and be able to open those files. We provide you that kind of depth. So there's a lot of extra functionality tacked in here. But that's not what I was about to show. Excuse me for getting sidetracked. I'm easily excited by my own product here.

So we'll go ahead with this foo.jsp. And with this jsp, of course, what we can do is write HTML. So I'm going to write just some basic HTML here. You'll notice that the structure pane gives you the same ability to jump to tags as it gave within-- within Java source. So my body's not going to be especially interesting.

But how about the random number for the day is? And we'll go ahead and spit out the random number for the day. You'll see that these special tags are colored differently. Why? Because they're an indication of something very interesting. We've now switched from HTML mode, where we're syntax highlighting in HTML, to Java mode, where we'll start recognizing Java keywords, things like if. That's pretty cool. But it's even cooler when you start doing something like out dot, and it recognizes that I'm embedded in a JSP, and out has a meaning within a JSP. It's a variable of a particular type, and code insight kicks in.

And shows you these are the various methods that you can use here. So our coding tools work even in this hybrid environment, which is extremely powerful. and I could go ahead and print something in here, what have you. What I'm going to do is just go to a prefab project just to save time.

Where I have a more sophisticated example. This calendar JSP goes through and uses embedded Java, as you can see, a mix of Java and HTML, to create a calendar for the current month with the current day selected. All I need to do to run that is just go ahead and say web run. And what we'll do is notice, hey, you're trying to run a JSP. Let's make sure that that's legal first, so we'll precompile it so that you can fix any errors within the IDE.

Then we'll go ahead and start Tomcat. Why is that interesting? Because Tomcat is the JSP engine for Apache, which, of course, is your web server, courtesy Mac OS X server. So we're testing using the same underlying JSP engine that you'll be using on the server side. We then feed it the JSP, take the results of processing the JSP, and show it in our integrated HTML viewer. So you've got the complete experience, end to end.

Pretty cool stuff. Along the way, and we'll just shut that browser down, and you can, of course, see the actual source that was emitted. If you want to have a look at exactly what was emitted, etc. We created this web app, and a web app is this servlet context.

A web application defines a context. It also defines a deployment descriptor, which we provide a graphical editor for, so that if you want to build a web archive, you can do so just by going ahead and building this particular web app, and we'll build the WAR file for you and do all of the packaging that's required in the WAR file to include the actual executable code, the JSP itself, etc., etc. So a lot of technology bundled together.

I also mentioned that we can do Web Start bundling for you. And if you want to take an application and deploy it to Web Start, this is pretty powerful stuff. So I've got an application, this Welcome app that we built earlier, and I'm going to use the Archive Builder to go ahead and bundle that up as an application for me and build the jar. Now I want to go ahead and turn that into a Web Start application. How tough is that? Well, we go to the Web tab and say I want a Web Start launcher.

I want to call this my welcome demo. It's going to use the default web app. That's fine. The jar file is the welcome jar that I just generated. That, of course, is the directory. This is the file. JAR files are a little weird that way. They're a little bit of both. And I want it to, yes, to go ahead and create that home page for me. I want to give it some meaningful information about the title, the vendor, the description, which can help the user understand what application it is they're installing, and finish.

And what it's done is it's built the HTML for Welcome Demo for the Web Start application. So if your user were to go to this page, what they would get is this message that says, "Hey, you don't have Web Start installed. It's a plug-in for your browser that allows you to automatically download Java applications, and you need to install it like any other plug-in." This page automatically detects that the plug-in isn't installed, gives you the information about where to go to get the plug-in.

Unfortunately, Apple hasn't finished the plug-in just yet. So it'll be up there as soon as the Web Start project is finished, and your users would be able to get at it. But it's also built the other piece that's necessary, the JNLP file, which is an XML file that contains the information about my application and its structure. So it's done all the work necessary to go ahead and build a Web Startable application, which is pretty cool stuff.

So hang on to your seat belts. We'll keep going here at this pace, and we'll jump right on into the debugging side of things. Just quick pulse. Are we going way too fast, or is this about right? Good? OK. We'll keep moving. So let's launch into the debugging stuff.

I'm going to go and open another project that I have lying around in my home. That has a couple of really simple things that we can examine and manipulate for debugging purposes. I didn't cook up anything that had any bugs, I'm sorry. But if you want to see the debugger at work, you just need to know that you have certain facilities that you've been used to all along. So what we'll do is we'll just place the typical line break point in this and get it started. Launch the debugger. The debugger needs to know the main class, which apparently I never bothered to define.

And it brings up a user interface at the bottom of the screen that gives me my full debugging power while still having access to everything else in my environment. I can still switch between multiple projects. I can compile things. I can edit code. I can do everything I want. And there's a debugger down there.

And you'll note the debugger has a tab at the bottom of the screen. Why? Because you can have multiple debuggers open concurrently. So if you're working on a client server application, you can be debugging the client and the server simultaneously. Each one has a full debugger user interface. Just, you know, little tidbits.

It's pretty cool stuff. It means that I now have full control over any data type in my environment. I can actually go in, and I can cut objects. Let's see. There we go. You don't have the key bindings I'm used to. So I can cut this object, and I wind up with a null value. But I could also go through and change this value by selecting Change Value. And I am asked to enter an expression of type string, by which I do not mean just a collection of characters.

If I wanted the collection of characters, sure, I could go ahead and type that in. I mean, if I want to change this, I can now create a string by doing something like, say, oh, this.getClass.getName. And we'll get the name of the current class and set that, debugDemo.debugName.

So pretty slick stuff. A very, very, very powerful debugging environment. We won't go through all of the features, but just sort of as a quick glimpse, we have the ability to set watches on individual items. So if I want to watch this particular object, I can create an object watch, call it buddy, and it will show up on the list of watches.

I can see all of the classes that are loaded. So if I want to see static variables, I could drill in and say that Java, IO, and Java. So buffered stream has a default buffered size, so I can go and examine static information, see the set of breakpoints that are currently set, add various types of breakpoints, go in and look at the breakpoints we already have, and say, you know, I'd like to log a message instead of stopping, or I'd like to provide a condition or a pass count. So again, a lot of flexibility on that.

And get a list of all of the classes for which I'm not interested in stepping into them. Have you ever before done the step into and then realized, oh no, I've stepped into somebody else's library and I'm debugging their code, but step over is no good either because you've got this huge expression that calls a few of people's other methods and then calls one of yours. Well, here you can block particular packages or particular classes from being traced into, and we block all the Java ones by default.

Or you can trace into them. That's your choice. So pretty powerful stuff. And lastly, there's one tab at the top that I'm going to show you. It's called the top here. You see this little screen icon that if I step over something that sends output, will go green to indicate that there is output waiting for me, console I/O, from my application. And actually, you can type into this as well, and it provides a full console I/O. So if you're not doing a graphical application, you again have everything you need to work on your server-side app or your console-based application directly within the environment without having to turn elsewhere.

And we'll turn back to the slides. XML. Somebody managed to miss the XML revolution. It seems that this has taken over. All of us are now to do everything in XML. According to some magazines we should stop programming in Java and program in XML. Other magazines would tell us that in fact XML will simply solve all our problems. And in reality those of us who've worked with it a little bit, just enough to get the feel for it, understand that what XML is, is it's a very powerful tool for solving a very small part of every problem.

So if every single problem is going to be solved this way, then I better have some tools to work with XML because it's not going to solve things for me. I better have some basic understanding of what it is capable of and my tools had better let me work with it. And that's what JBuilder does is it provides XML support not in terms of being an XML IDE but providing the kinds of things that a Java developer is likely to be interested in because you're going to interact with XML a little bit. Everybody is.

Blake Stone So XML support provides us some basic navigation and editing facilities, validation facilities, DTD generation, and transformation. XML by itself is neat in a way, but XSL, which allows me to provide a style sheet for transforming one piece of XML into another piece of XML, is much cooler still. So we'll show you what we've been working on, what's new in JBuilder 5 in terms of XML. I'm going to go and open a sample project. It actually comes with the product. We provide zillions of little samples to help you get started.

Yes, I'm sorry. Let me just make sure that, yes, there's a demo. That was your cue, I'm sorry. If I drill down into an existing project here that's designed to showcase some of the XML functionality, we'll see that what we have in here is a DTD and a couple of XSL files. We can look at the DTD.

It's exciting if you are into that sort of thing. We can look at the XSL files. And you'll see that we do syntax highlighting for them. We recognize the file type and we provide syntax highlighting. We provide basic navigation facilities. So that's pretty cool. It gives you something.

But a DTD is interesting partially because it describes what a valid XML file looks like. So one of the things we should be able to do is take DTD and say, you know, I'd like to generate an XML file that complies with this, that uses the XML employees as the root element.

And I'm going to go ahead and specify that we're going to use the system DTD here for... is a great example of how to use Blake Stone to get the most out of your data. So, we've got some XML here, and again, we have the same sort of structural view here that we can parse through and find any of this information.

It'd be kind of nice if I could come back and validate this particular XML, and sure enough, we can say validate this, and we'll figure out what DTD it's involved with. And apparently, ah, I specified the wrong path to get to it, so it is invalid, but let me validate that again, and it is valid. Now, if I make a mistake in it... First thing you'll notice is our little error insight kicks in and says, hey, this doesn't even balance.

So you don't need to go all the way to validation to find out that this isn't even legal XML. We'll find that for you on the fly. But once you get to the point where this is legal XML and you want to know whether it really complies with the DTD, that's a little bit more like the compile pass. And we'll do the validation, tell you where the error is, and then you can go through and actually correct it. Blake Stone So that gets you some of the sort of mechanics of working with XML.

But transformation is what's really important. You get your raw data this way, and if you wanted to present it to somebody, you need to transform it into something other than raw XML. And the typical thing to do is to transform it into HTML. Blake Stone So if we go to the transform view, we provide you the ability to pick any style sheet, and it's just telling me it couldn't find a style sheet for that particular one.

And then I can pick one of those, the list view or the table view, and it shows me the output of this. Now the output in this case isn't necessarily exciting because it's going through another style sheet, which I'll talk about in a second. But if we turn that off, then you begin to see where the power of XML comes in, is this ability to take this raw data, transform it, and show it to somebody in another fashion.

So now if I go into my raw data, It's actually here, isn't it? And say, I'd like to change this by declaring another employee perhaps Steve Jobs, and go back to my transformation view and refresh that. Then we'll go and apply that same transformation and get this dynamic data thing going. So this is a set of tools that doesn't solve your problem, because XML doesn't solve your problem.

It's a set of tools to help you get familiar with XML, to help you start learning what XML is capable of, and to take advantage of some of the XML libraries that we provide, because we provide the Xerces parser and so forth, and we provide the libraries that define those as part of your environment. So that's hopefully an exciting first look at what we're doing with XML.

So if we can get back to the slides here. That's all well and good. You know, we can do pure Java development. We can do a bunch of cool stuff with Java beans. But if you're a Macintosh user, you know there's nothing quite like your native environment. And you've seen hints of some of the facilities that are available. If you went to Steve Llewellyn's talk on wrapping Cocoa APIs in Java beans, very cool stuff.

The speech synthesis and recognition and spell checking neatly wrapped up so that you can just use them in an environment like JBuilder. And that's a hint that yes, you can get direct access to Cocoa stuff from within JBuilder. So you could just drop those beans in and take advantage of it.

But in fact, you could go a little bit further than that. You could go through and start writing Cocoa applications in a pure sense. So we'll look at that. But we'll also talk a little bit about how JBuilder... So JBuilder helps you with new classes in general. Because Apple provides you with a bunch of classes that may not be familiar.

If you're an MRJ user, you may know some of them already. If you wait around a little while, there's going to be a bunch more. And what's important about JBuilder is that it dynamically adapts to any new class you can throw at it. So all of our coding tools, Code Insight technology, our class browsers and so on and so forth, will learn about new classes that you throw at it and give you those same kinds of help.

So we'll look at that a little bit as well. But when it comes right down to it, you're going to be left with a choice. You can use these tools to do pure Java in a cross-platform sense or write pure Java code that really wrings every last ounce of performance and flexibility out of the Macintosh platform. We don't make that choice. The choice is up to you. So let's have a little bit of a look at what we can do in this area.

Now, you may have noticed I don't really believe in scripts here. I kind of like winging things an awful lot more. So this is sort of a first crack at some of this stuff, and I'm still waiting for answers from a couple of Apple engineers because I started thinking about this on Monday.

But it's really interesting to see that I can sit down and write an application and take advantage of the right way to do a Cocoa interface, which is not Java Bean, so of course that means Interface Builder, and all the power of JBuilder and meld them together. So we're going to use JBuilder, and we're going to use Interface Builder, and we're going to tie the two together into a brand new project.

So if I create a new project... Within this project, I'm going to create a new class that's my main class. And let's give this a slightly better package name. So I'll put this in the Cocoa demo package, and we'll call this Cocoa demo perhaps, generate a main method.

And keep my fingers crossed that I actually remembered what I was doing and brought along My Cocoa main. Please excuse me. Okay. Not entirely scripted, but I didn't want to torture you by going through this. What this is, is it's the stuff necessary to go and find a nib file and open it up. And I'm going to go with cocodemo.nib.

But of course, we could deliver this template with JBuilder. We haven't actually finished JBuilder 5 for Mac OS X. We haven't signed it off, so maybe I'll sneak that in at the very last minute. What this does-- some people would like that-- is it gives you the framework necessary to call this nib in and get things started and running as a Cocoa application.

Now, if I was really starting from scratch on this, and I had no real idea of how to get to some of these classes, So long as you tell JBuilder about the path, and so I'm going to add the set of Cocoa classes to the path, JBuilder can find out dynamically for you about things like, oh, I'm going to need to import some of the right things. Let's see, com, apple, Cocoa, and is the founder of the Mac OS X-specific foundation. So you can see it helping me already in finding the correct import names because I don't remember them offhand, and application.

So that if I go and ask, you know, what are the methods for NSBundle? It'll show me the bundle for class and bundle with path methods. It will show me that for bundle with path, what I need to do is pass it as string. So all of these kinds of things are a lot easier to find. And it's not because JBuilder knew about them ahead of time.

It's because I added those classes to my class path, JBuilder found them, and did the right thing with them on the fly. It can do an awful lot more if it can find the sources in terms of parameter names and so forth, but even just the raw class files give us an immediate start. So now we have this particular application. It's not all that exciting because there is no Cocoa.nib. Let's go ahead and get interface builder involved in this.

So what I'm doing, of course, is assuming-- thank you-- the developer applications are installed on this machine. This is a developer's conference, after all. And I'll bring Interface Builder up, and we'll go and open an example nib file and have a look at the way it's structured, what's been set up in it already.

So if I go and open from my--quick question because I've been an Apple advocate for a long time, but I've got to admit I was out of it for a while. Does everybody intuitively recognize this as the option or alt key or is it just me? You know, has that been a standard long enough? Sorry. That just, it gets to me.

So I'm going to go ahead and open this CocoaDemo.nib file that I have, and we'll have a look at it. This should be really familiar. Everybody built this application at least once in Objective-C, and if you've gone through the Java tutorial for how to build this stuff with Project Builder, you've also seen the same one.

What we have here are the Fahrenheit and Celsius fields that we can type into, and if you look at them, you'll see that, sure enough, when I hit enter, they'll send an action that I've got a temperature controller, and if we look at the temperature controller class... "Which I have here called converter. It has outlets for Celsius and Fahrenheit and an action convert. And surprise, surprise, I've got all these things wired up so that you can get to the appropriate fields and the fields both fire convert. methods when you hit the Enter key.

So I've got everything I need in place. All I need to do is go ahead and save this nib in my project.

And then go ahead and generate the source code for Cocodemo.converter. So I'm going to go ahead and create files. Say I want to go ahead and generate that one into my source. Oh, that's going to be bad, isn't it? I mistyped the package name.

We'll go ahead and correct that and see a few other JBuilder features while we're at it. You know, this is why I made this little comment about this is live. I don't really script all this stuff to the nth degree because I believe I can probably fix this sort of thing on my feet.

So, if we go into my JB project directory and look at source CocoaDem and change this to CocoaDemo, what I've done, of course, is change the structure of my project. And within JBuilder now, if I just refresh, it notices, hey, your source has changed. You've got a different package.

So we'll go ahead and change this to Cocoa Demo and get that right. And we've also generated this converter. And so the converter that's been generated for me by Interface Builder, because Interface Builder understands Java, Apple's right with the program here, is it's generated this stub here that has the appropriate object references that Interface Builder is going to go ahead and set when I instantiate this nib. And it's got this convert method. All I need to do is fill out the convert method.

Well, I hope you're not too entirely shocked that I had the converter pre-written as well. So just a little thing. I don't know if this means anything to you. It means a lot to me. If I go ahead and take that same template and expand it elsewhere, it pays attention to the indent level. You know, it's the little things that matter sometimes. Thank you.

And if you look at this converter, it's not all that exciting. It plays a sound just because it can, and then checks to see who it is that sent it and converts the temperature and stores the result in the other one. So I should have here an application that if I go ahead and run and specify my main class here, and it's Cocoa Demo.

That we actually should get-- and let's go ahead and hide interface builder, because it's going to confuse the situation here. We should have gotten the user interface. Let me just very quickly scan through this and make sure that there's no surprises. : Cocoa demo converter. What's a J button? : It's an import. : It's an import. Oh, my main class is a button. Oh goodness, that's evil. Thank you.

That's what I get for going through this quickly. So let's recompile that. And run it. And so we get our temperature converter over here. We can go into the temperature converter and type a value. We get the conversion. And what we have here is a Cocoa application. Very, very cool stuff.

I've got to fess up to something. It's not a full-fledged Cocoa application. By the time I get a few answers from a few more Apple engineers, it will actually have an icon on the dock. But that's what we're all here for, right? Get answers to the ponderable side here. But let's go one step further. We have a Cocoa application. Let's go ahead and drop a breakpoint in our Cocoa application and go and debug it from within JBuilder. So we can compile this. We get it started.

We'll get our UI over here and go ahead and type in a value. If I go from the correct field, I probably put the breakpoint the other direction. There we go. We'll hit that breakpoint from within JBuilder, and then inside JBuilder, I can start examining things, and I can see... Put this in the correct place.

I can see, for example, that sender is an instance of NSTextField and Celsius is an instance of NSTextField. And I could even go ahead and take advantage of what we like to call the world's largest tooltip and click on one of these and browse those directly in place and see what we can see from the Java side of the bridge.

Perhaps not a whole bunch, but it's sort of interesting to start examining the internals of Cocoa directly from within a Java debugger. So again, Cocoa from Java. This is something that we're going to spend some time researching and make sure that it's an option that's available to you.

So if we can flip back to the slides. JBuilder is a really interesting product from a lot of points of view. I love that it's written in Java. I love that it's actually the same object code, not just the same source code, but the same object code running on all these platforms. I love that the first time we got the debugger up and running, we took it to Solaris and said, what happens if we run it over here? And the debugger worked on another platform the very first time we tried it.

This is really good. It's really compelling and powerful stuff to me. And as potential Java developers or as Java developers out in the audience, it should be equally exciting from your perspective. But I really like how dynamic Java is. So when we had a chance to redesign JBuilder and really put everything in Java, we took advantage of it and really to the hilt went for dynamic discovery of features. It's what we call the JBuilder open tools architecture. It means that JBuilder, when you launch it, learns about the things that it can do.

It's what it can do from scratch every time. You may have worked with other people's plug-in architectures before, and you may have seen that what's typical of a plug-in architecture is that the plug-ins let you do some cool things, but that there are a lot of things that they did that you can't do through the plug-in architecture. Well, JBuilder is written with its own open tools architecture.

That means our designer is just a viewer plugged into our open tools architecture. All of our editor key bindings are plugged in through the open tools architecture. JBuilder itself consists of close to 300 open tools loosely clustered together. In fact, if you remove all of the open tools and the libraries they use, there's one class and one interface. That's it.

So it's a pretty powerful framework, and it's one that we strongly encourage other people to plug things into. So if you want to tailor the environment, you can. You can add new viewers, file types, editor behaviors, dialogues, and much, much more, to use the typical phrase. But we mean it. I mean, this is powerful stuff.

We've seen third parties do very, very cool things using the open tools architecture. And if you look around, you'll find that there are a number of application server vendors and big companies who have products that they'd like a Java IDE for. But instead of inventing one from scratch, they can just tailor JBuilder and make it work for them.

What's especially cool about that is anybody who writes an open tool has to write it in Java. And if it's written in Java, it probably already works on Mac OS X. So all of those open tools that have been written, you can take advantage of them the day JBuilder hits the street. And in fact, if you're brave, you could probably take the copy that's in your bag, go home, download a couple of those open tools, and start using them today. So that's really compelling stuff.

As I was in the prior session, I realized I wasn't planning on making a USB device anytime soon. I just really wanted to be in the room, and there was not that much point in my paying a lot of attention. So I spent the last half of the session writing an open tool that sort of just occurred to me. And let's have a look at what you can do in half a session when you're worried a little bit about battery life and everything else that goes along with that.

You can take an idea and almost get it all the way. Well, if we can, oh yes, my apologies. I keep not going to the Clue slides. I'm probably their least favorite presenter by this point. Blake Stone I'm going to go to my home and have a look at AppWrapper. Because one of the things that people will point to JBuilder and say is that, you know, obviously it's a pure Java environment. They build jars, they build wars, they build rars, they build, I mean, literally, these things are all valid acronyms, ears, etc.

But what about a double-clickable application? And it just, you know, we're trying to get the first copy out to get things going. We're trying to get things going as fast as possible. And building a double-clickable application was just too late in the cycle for us to put in the product.

But as an open tool, it's a very different story. So what I did is I sat down and looked at the process of what it would take to build an open tool that gives you a double-clickable application. And just to give you kind of a quick sample, this is all the code.

And just kind of what it does, the initialize open tool goes into our project view mechanism and registers a context action provider. So that means that in our project view, if we bring up a context menu on something, we should be able to now have new functionality registered.

And it goes on to say this functionality should only show up if you have a single thing selected and that thing is a jar file and it should bring up something that says create app wrapper for this jar file and then go through the motions of creating the basic structure and copying things into it. And if I had any of the documentation handy, I would have actually used the standard MRJ app builder, but instead I just sort of rolled my own.

This allows me then, theoretically, to extend JBuilder. Well, let's go ahead and compile it. You'll notice the compile took a whole bunch of time. And what it did was built this app wrapper jar file that contains the necessary class and a manifest file that tells JBuilder that, yes, this is an open tool.

If I were to go to some application in JBuilder without modifications, such as my welcome application, and bring up the context menu for a jar, you'd see that it has a variety of options, but it doesn't have anything for an app wrapper. Well, let's change that. What I'm going to do is not save all of this. I suppose it doesn't matter. What I'm going to do is go and find a directory that contains all of our open tool definitions.

It's in JBuilder 5. It's a directory called Open Tools. It's actually installed as user writable so that you can drop things in like my tweak to turn on hardware graphics acceleration here. Or in this case, go into my AppWrapper and find that jar file, drop a jar file in, and restart JBuilder.

That's it. So the installation process is pretty straightforward. You drop something in the open tools directory, start the product, and at launch time we dynamically discover new capabilities. And this new capability in particular should be that it can create a double clickable application. Now I will admit I came down to the final seconds of the session and I had a bug left.

So it gets almost all the way and I'll show you what we have to do to get it the rest of the way. Go to welcome jar and note create app wrapper for welcome jar now just shows up. This is one of the zillions of places you can plug things in. If you'll excuse me while I sort of take a divergent story, we actually got a message through tech support from a fellow working for a company that said I'm trying to write a whole new file system based on XML and plug it into JBuilder. And it worked.

It works fine. I can open things and so forth, but I need to be able to go ahead and add to my source path pointers into my XML file system. And we were able to actually tell them, well, that's nice because the open dialogue actually allows you to extend the set of root elements in the directory browser with things in any virtual file system that you've written in Java. So little things like that are getting done by people out there.

Why? We built the architecture for ourselves and we've just opened it. We've opened it to the rest of the world. I'm sorry, again, a little bit of a sidetracked topic, but let's go ahead and create app wrapper for this. And boom, it's gone off and it's done the basic work.

If I were to actually go to that welcome project, and the welcome project is in our samples in the JBuilder framework. Welcome. I'd find welcome.app. So it's built me a little app wrapper. Unfortunately, it's left out one line in one file and forgotten to set the executable bit on something. Sigh. Last minute demos. I thought you'd be forgiving. You're a developer audience after all, and real demos are always much better than canned demos.

So let's go in and have a look at this welcome app and it created Does everybody else get 2Ds sometimes? Let's see. It's left off one line in-- not the executable. It's left off one line in a config file. To specify the main class, I should have known. And it's forgotten to set the executable bit on Java Launcher. I'll get both of those things in there shortly. We should have-- see, it's on the dock. It should be loading bits and pieces of swing as we speak.

And have I-- yes, live demos. Does anybody remember the last thing I did in Welcome App before I turned it into a double-clickable application? Let's see what the launcher does. Activating lightweight. xy layout. I didn't bundle my xy layout, which I was still using in there. So you can see we have got double clickable. It shows up on the dock. If I had code that would actually execute, it would actually run it.

So to clarify, of course, this isn't a feature of JBuilder. This is a feature I whipped up in a few minutes during the last session. You can do the same. We'll continue to do the same. And we'll continue to make sure that if we find cool things we can do on the Mac OS X platform, open tools are one easy way to slip things out the side door without having to wait for another release of the product.

Blake Stone One very last thing, by the way, because it never gets brought up, and is it a Macintosh-like thing? No. But some of us here have to deal with reality constraints. How many people here have to automate a build process for a project? Right? Graphical tools work real well for that.

You run into some problems. Blake Stone So one of the things that we did is made sure that JBuilder actually has a command line behavior. Blake Stone So in this case, we can say things like, "JBuilder, build the project at developer applications." Let's see if I can find this one again. Samples, welcome, welcome.jpx. And it'll kick up the command line version of the JBuilder build process and do everything in my project definition. It'll check the Java dependencies, compile necessary files, build archives, build war files, ear files, you name it.

It's the attention to detail that makes it obvious we've been at this for a little bit. So if we can switch back to the slides. The preview CD you've got, I want to mention really briefly, you definitely must get Apple's Java VM update. Yes, you can run it on Mac OS X, the initial release.

We'll bring up a warning letting you know that it's going to be a little bit suboptimal on that release because the debugger really desperately needs some JDK 1.3.1 technology. And also, of course, we benefit from a lot of the work the team has been pouring their hearts into over the past couple of months since the release of Mac OS X. You need to go to the Borland community site to get a license.

But don't worry, you can opt out of any possible contact, so we'll just make sure that we get the license key to you. But if you're interested in JBuilder information, then that's a way to make sure that you get further information from us to let you know when JBuilder for Mac is actually going to ship.