TNC: Welcome to the show. My name is Philippe Lourier.

A few practical issues. If you're listening to us live, you can join us in the chat room, and the room is #tech.technetcast. Or you can visit our home page, technetcast.ddj.com, with your java-enabled browser and click on the chat links. Make sure you join the right room, #tech.technetcast.

And if you want to call in questions, you're welcome to do so, and the phone number is 212 965-1390. You will be put on the air.

Our guest today is Bruce Eckel. Bruce has published over 150 computer articles and books, and six books, including, most recently, "Thinking in Java." His earlier book, "Thinking in C++," received the Software Development Jolt Award for best book published in 1995. Bruce is also the author of the Java Alley column in Web Techniques magazine, and his articles have appeared in numerous other publications, including the C++ Report and the Dr. Dobbs Journal.

Bruce, welcome to the show.

BE: Hi.

TNC: Actually, we met once at SD '98 a few months ago.

BE: That's right. You interviewed me with a camera.

TNC: It was very quick, five minute interview. We had a little stage there and speakers from the conference would come in and talk to us.

We have a camera here but you can't see it because you're either at your not in the studio, but there is a camera, and people who receive the video feed can actually see your book on their screens right now, "Thinking in Java."

And actually, there's a story to this book cover, isn't there?

BE: Well, yes. There is somewhat a story to the book cover. The process of putting the book together was, I guess I've done enough books to where I get each one I want to do more and more myself. And this one I decided that I wanted to have complete control over it. And so I got an agent. And she found -- well, oddly enough, the editor that she found turned out to be the first editor that I'd used. He'd just changed companies.

But he agreed to everything and a very good friend of mine who's been doing all of my design work ended up doing the cover. But we went through a bunch of different versions and I kept saying, well, I wanted it to be more -- you know, I was kind of vague and it was a bit frustrating for him.

But both of us collect arts and crafts kind of furniture and things. And I like the period. And it was, the arts and crafts period actually started towards the end of the 1800's, kind of -- well, I like to see similarities between the end of that age and the end of the age we're in now, where there was some radical new technology showing up. In that case I would say the car. In this case, it's the Internet. And then at the same time there was some reaction to that and the reaction in the case of the arts and crafts movement was a movement towards more hand-created, handmade -- it wasn't the they were Luddites and wanted to get rid of all tools. They just wanted to have tools that would allow them to kind of have more, the feeling of more of a handcrafted thing, high quality products and stuff like that.

So I feel like that's kind of what Java gives us. You know, we've gone through the earlier processes of programming languages where all of the wheels and pulleys are bare naked and they can, you know, suck the arms of the programmers in and chop them off and all that kind of thing. Whereas Java is, you know, we're kind of on to the next generation and we've got something that will, in a sense -- well, in a very real sense protect the programmer from all that rotating equipment.

TNC: Just for the benefit of listeners, the book cover we're talking about is, the cover of your most recent book, "Thinking in Java" --

BE: Right.

TNC: -- published by Prentice-Hall, 1998.

We have to take a quick break. We'll be right back after these quick messages.

(Commercial break)

TNC: We're back with Bruce Eckel, and our topic today is "Thinking in OO". I just want to acknowledge some of the listeners in the chat room. We have, among others, Ken, Ollie, Soiga, WhoDat…

Hello, guys. We'll be taking your questions.

Bruce, I'm wondering about your background. How did you start programming?

BE: I guess I was -- I'm trying to remember whether I was a freshman or a sophomore in high school. And we had this very bad math teacher, but he did teach us to program in basics, us in Basic, using one of those old ASR33 teletypes that was connected via modem and all that kind of stuff. And it kind of stuck.

I didn't do any actual programming except for those few months, until I had gotten into college. And then I wandered off into journalism and drama and photography and those sorts of things. And in my first year of college I was going to be -- well, I decided to be a journalism major because I liked writing or publication and all that. And after a year I realized that I had learned probably more than I was going to learn already. So I decided that I needed to do something really challenging. So I changed to physics and I spent four years doing that. And that was really too challenging, and almost too challenging. And then I started taking some engineering courses and discovered that even getting beat up in physics you could do really well in engineering. So I liked that and stuck with it.

And finally, towards the end is when I started taking more programming classes. But I hardly took any of those. I ended up in computer engineering and so, you know, put chips together and very low level stuff.

But it turned out in the end that that was very nice background to have, even though most of the programming was self-taught. And when I was actually hired, it was not a chip guy but as a low-level programmer.

TNC: So your first job was actually as a programmer.

BE: Yes, it was. It was computer engineering and it was really -- I mean, it was all assembly language stuff and we really were working to program a particular piece of hardware. It was embedded systems programming, is what it was.

TNC: So how do we get from there to your involvement with the C++ committee? How did you get to be a founding member of the C++ committee?

BE: Well, what happened was I missed writing. I missed being on the newspaper staff in college and all that. I missed the camaraderie.

And so I found this little magazine, "Microcornucopia," which some people still remember, and some remember quite fondly. I certainly do. And it's, I started writing for them and just never stopped. And eventually I got -- well, I got more interested, I got tired of all the stuff that had to do with lower level languages, and when C++ came along it caught my interest. But all we had to start with was Bjarnes's book, which was very difficult going.

TNC: So this was what year, approximately?

BE: This was probably 12 or 14 years ago, something like that. And let's say -- is that right? Well, roughly '85, whenever his book came out is when I first noticed it.

It was overwhelming, and it took me another year or so before I actually ended up with a job, working with Tom Keffer. It was just he and I. And he later went on and created Rogue Wave and is now kind of a hippy millionaire who doesn't know what to do with all his money.

But, anyway, it was just him and I working on all this stuff, so I had to delve into it. But eventually, because I was doing consulting and writing about C++, there were some contacts, some consulting work and a publisher contacted me and wanted me to write my first book.

TNC: At that time, were you mostly programming or mostly writing?

BE: I was mostly programming and I was writing the occasional article. The first article for "Microcornucopia" took me a year to write. I was doing hardware and software. I was basically programming low-level hardware through KPRO's parallel port to make stepper motors and LED's turn on and off.

So it really took me a long time and a lot of effort. And then they took the article and broke it into two pieces and said, "Okay. And we want more after that." And they published every two months.

And so it's only been over many years that I've gotten up a certain amount of speed in writing.

TNC: It's a habit.

BE: Well, yes. It's very slow going and I'm not one of those people who feels like you have to write every day, because I don't. It ebbs and flows. But it's a regular thing but --

TNC: So how did you get on the C++ committee?

BE: Well the book came out, and at the same time I moved to Pennsylvania for other reasons. And I had known Bjarne and all these other folks from conferences. And the organizational committee was going to take place in Washington, D.C., which was about 100 miles away from me. And I thought, oh, well, I'll just go down and see what's going on. Maybe I can learn something.

So I was down there and I remember, you know, telling Bjarne that, well, I was just checking it out. And he was saying, "Well, you know, you should consider being on the committee."

Being on the committee wasn't like you had to be anybody special. You could just join. But you had to commit a certain amount of time every year. Three weeks a year, roughly, to maintain your voting membership, which felt important to me.

So it was really a matter of persistence and going to the meetings that kept going. I realized that it was better than graduate school, because here were all these people who really knew what they were talking about. If I had any questions, I'd just save them up for the meeting, and then I could go and start talking, start asking questions. And within a few minutes I'd usually have my question answered.

Because half the time, the people who had created [the language] came to the meetings. For example, Jerry Schwartz -- who designed the IO strea library-- and I could go ask Jerry, "How is this thing supposed to work?". And I got a lot of it like that.

TNC: Right to the source.

At the time, what was your grasp on the language? Were you still learning it?

BE: I'm still learning it now. Yes, I'm always learning these things. I'm working on the second edition of the C++ book now, and I continue getting insights on issues such as the Standard Template Library.

Sometimes what I tell people is I think my advantage is that I am rather a slow and dense learner. It takes me a long time to understand these things and I have to keep beating against it. And because of that, I understand what my readers and what, if I'm giving a seminar what somebody in the audience is going through. And so when they ask the questions, I usually know exactly how they got where they did.

On the down side, you know, there are people who are in my audiences who are just brilliant and they pick these things up really quick. It takes me longer and I have to slog against it and write all these little examples to try everything out.

TNC: You have to iterate. It's actually one of the themes of your book, iteration. The learning curve is probably what keeps a lot of programmers going. New technologies come along, and there is always more to learn about older technologies. It's exhilarating.

BE: Exhilarating and sometimes daunting. And also I think you have to know where to draw the lines.

Java, for example, is even harder because they have these vast API's, all of which can be very seductive. As I said in this book, my focus is going to be on teaching people the core of the language and I'm not going to talk about the 3D API or the telephony API or anything like that. But I'm going to give people the equipment so when they go and delve into these themselves. They won't be thrown any curves. So that's what I was really focusing on.

And there will be specialty books covering the rest of the stuff.

TNC: What you're really doing is giving them the tools to manage complexity. Here is a quote from your book, "Programming is about managing complexity."

BE: A lot of things are about managing complexity, but programming is [about managing complexity]in the most pure form because of the struggles that we encounter whenever we're trying to make bigger and bigger programs. A programming language like C++ to a large degree, and Java, too, to an even larger degree, that assists you in managing that complexity is one that is more successful than one that doesn't, like C or assembly language or earlier languages.

TNC: The titles of your books are "Thinking in C++," "Thinking in Java." Does this refer to the fact that to address these complex problems you need to really immerse yourself into a certain way of thinking, a way of thinking that the programming language uses?

BE: That wasn't what initially made me think in those terms. It's just that when I immerse myself into these things, what happens is eventually what I have heard, and I've never gone through a foreign language to that point. But I hear that after immersing themselves into a foreign language to a certain degree, people actually start thinking in those terms and dreaming in those terms.

I think what I meant more by those titles is that the language that you think in is what determines what you're able to think about, or in this case program about. So if you do think in that language then you have a medium of expression that will allow you to range according to what -- well, for example, I am able to think about different things and larger things in Java than I have spontaneously in C++. Now when I go back to C++ and look at it, I have a broader view of things. But I think it was really Java that allowed me to do that.

TNC: So you're really talking about the expressive and conceptual capabilities of the language.

How would you compare Java and C++ in those terms?

BE: Well, I've tried to do that. I even put an appendix in the book. But that wasn't, I think, what you're talking about here.

I'm still learning what is possible to think about in Java. But one of the things I've discovered is that certain things can dynamically extend themselves. The creation of a program, for example. You can have a program that's running and then you can add new features to that program dynamically.

Well, that's one of the things that Java just does. And you can set that up in just a few lines of code. Whereas in C++ you don't really try to, you avoid thinking about a problem like that because it's too complex.

TNC: You would be able to do it, but you'd have to build it yourself.

BE: And the building of it is one of those mind-boggling problems that you tend to get distracted away from, whereas with Java you just go, "Sure. Yeah, we can do that." And, oh, other issues like cross-platform problems.

Well, Java isn't perfect for that, but still. The way that I like to look at Java is that it tries to solve the hardest problems for us. In order to make our life easier.

And I didn't get that at first, so I was a little annoyed at some of their hype. But when you do that for me, that endears me to somebody.

When they say, "I'm going to try and make life easier for you" --

TNC: Here's a quote from your book that supports this: "What has impressed me most as I have come to understand Java is what seems like an unflinching goal of reducing complexity for the programmer."

Bruce, we have to take a quick break. We'll be back after these messages.

(Commercial break)

TNC: We're back. My name is Philippe Lourier.

We're back with Bruce Eckel and we're talking about C++ and Java, and more specifically about his most recent book, "Thinking in Java," available from Prentice-Hall. And you can also find at fine bookstores everywhere and also at amazon.com. I'm looking at the amazon.com page here.

Actually, this is strange. I'm looking at the page and they have no publisher information. They just say, "Thinking in Java" by Bruce Eckel. And the price.

Oh, there it is. It's in small. Published by Prentice-Hall Computer Books, March, 1998.

BE: And I think they say that it's five -- they might still say that it's 500 pages long.

TNC: They say 1,100.

BE: Oh, they do. So they fixed that. Okay.

TNC: They fixed it. They even give the weight and the dimensions. So anything you need to know about the book is there.

BE: Right.

TNC: And I also want to mention your Web site, Bruce. www.EckelObjects.com.

BE: Well, I've gone through a number of domain names, but I finally realized that the easiest one for people to remember is just www.BruceEckel.com. That's just my name run together. It's actually at the bottom of the book cover.

TNC: And what can readers find at the site?

BE: Well, they can actually find the entire text of the book in various formats.

TNC: This is actually a question from the chat room. Ken asks, "What prompted you to make this book available on the Net"?

BE: Well, part of it was just kind of boredom, because I had done other books in the past and a number of things came up. I was looking at turning 40 and saying, is that all there is? I want to do something different.

And I realized something else when I started doing my own public seminars. I've always done seminars through other people, mostly Miller- Freeman in the past. And I got tired of that. And so I said, well, this would be more interesting to actually do my own. And it was very exciting and a little bit tense at first. But I tried actually doing mail marketing like Miller-Freeman had done, and then I also published, put stuff up on the Internet.

And I think I sent out 14,000 postcards to a pretty good mailing list, and I think I got maybe one person came because of the postcards and everybody else came because of the Net.

I thought, well, I'll just use the Net.

The next question was, "How do I get people to come to my Web site?" And I had learned that people come to a Web site because they want free stuff and also if you walked into a store and they hand you a cup of coffee you're much more likely to buy something.

TNC: Or you can put up pictures of naked girls.

BE: Well, yes. But if I did, that would be a distraction, I think, from what I was trying to do… Who knows? Maybe that would address the needs of the programmer community. But that's not really my domain.

So, anyway, it was really a kind of "What the heck" thing to do. And I said, I'll try it. But I guess the real key was I started thinking that if I were to put the book up there and people were to download it and for some reason or another it, and it never went into print and I never got a cent off the book, and if people came to my seminars because of that, then I wouldn't really care.

Because you make more money off seminars than you do off books. So it started out that way.

But the result was I got all this tremendous feedback from people and corrections that were just terrific, things that I know I would have missed. And people will send in and correct all kinds of things.

And so by the time it was actually ready for printing, I had this large reader base, spread out all over the world. And, after some questions, I said, "It's okay, You can print these things out and use them for whatever". And the book was actually adopted at various universities before it was ever published, because I said they could do that.

Now, of course, that gave the publisher the creeps for a while. But I think they eventually realized that, yes, once they adopt it it's really hard for them to make that change to another book.

TNC: When was the book published by the publisher?

BE: Well, it just really hit the shelves. I think it came out officially at the beginning of February.

TNC: So you don't know how sales may have been affected.

BE: Well, as far as I can tell, very positively. Because they went into a second printing after three or four weeks. And my editor said it looks like it could become a bestseller.

TNC: Well, hopefully, publishers will look at this and do this much more. I think every book should be published on the Internet, and then you should be able to go and get a hard copy of it.

BE: I think that, too. But I apparently am not the first one to do this. It sometimes seems like it. But a number of publishers have apparently put a lot of their books up on the Web, and my editor in fact said that the previous company he had been at had done that. And he said that it seemed to hurt sales on some of the books.

But you know how computer books are. A lot of them are rather quickly put together --

TNC: To put it mildly.

BE: Yes. Trying to be diplomatic.

And so it's possible that if someone were to preview it on the Web then they wouldn't want it.

Roughly ten percent of the books make back the money that the publisher invests into it, and the other 90 percent lose money.

TNC: Technical books?

BE: Books. All books. So this is really a bad track record.

And so if you think about the way the Internet could be used here. If I were a publisher I would say, okay, let's put books up on the Web first and we'll put into print the ones that are popular. And the others, you know, why waste the money?

And authors could get higher royalties, the publishers would make more money. I think it's a model for the future.

TNC: Let's get back to Java here. The book is available on your site, www.bruceEckel.com.

BE: And the source code and also some lectures that are in RealMedia format and there's also the multimedia CD ROM of my five-day seminar, all the lectures and slides from that, as well as the book in a friendlier format for monitors and cross-index and stuff like that.

TNC: Before the break we were talking about how Java reduces complexity for the programmer. In your opinion, How does Java make it easier to write programs.

BE: It's a lot of things. But in general, it's the attitude of the people who have designed language. Of course they have made some stumbles. The old AWT was simply hideous, and yet the new Swing library is probably the best user interface library I've ever seen. Not only is it a cool design, but it's [well though out] from a programming standpoint. The method call to add a tool tip is SetToolTipText. I remember when tool tips first came out in Windows 95. Though they were supported in Visual C++, I never figured out how to do it, because it was so complicated.

I thought it was me, I was stupid, there was something that had to be that complex in the operating system. But then when you see this, which you can remember off the top of your head and is so straightforward both to write and to read, you realize, no, programming doesn't have to be that hard.

TNC: One of the strengths of Java is the way the toolkits and API are conceptually laid out.

BE: It's basically a one-to-one mapping between what you need to do and what you have to do, what code you have to write. So it gets more and more impressive over time.

I mean, the one real snag has been the speed. [For the rest], you just look out and go, "Wow, that's easy to write." Network programming is another good example. First of all, it's built into the language. But second of all you don't have to know all this low-level stuff about how big your packets and frame buffers are. It's as simple as they could possibly make it, and yet you seem to be able to do all the things that you need to do with it.

And so that, in itself, is wonderful.

TNC: Now, you say that one of the drawbacks is speed. But that actually comes with the territory. It's actually a function of the overhead, to make the language safe.

For example, Arrays. When you use Java Arrays, you can't overwrite past the bound of an array. But there's a cost to that.

BE: Yes. I've learned that my initial assumptions about performance have not always been correct.

For example, my experiences with garbage collectors in the past have been --well, naturally you've got this extra process running and periodically it's stopping your program and doing something. So, you know, it just seemed really impractical.

And yet as I began to understand how garbage collection really worked -- well, I should say how some implementations of garbage collection really works, like Microsoft's, in particular, is extremely fast.

TNC: In what application?

BE: Well, in their virtual machine.

TNC: Okay, the Java --

BE: Well, they're not calling it the Java virtual machine anymore. They're calling it the Microsoft virtual machine because, technically, it's not precisely Java.

But the virtual machine, itself, still runs the Java byte code. So you can load all of your other libraries, all of your other Java libraries, assuming that anything that requires the interface, native code interface has been taken care of. But if it's a new, 100 percent pure Java library, you can load it into theirs and use their virtual machine, and it runs really fast.

But Sun is getting a lot faster, too, and other implementations are getting faster. But the way that the garbage collector works can actually be faster in many ways than the way you do new and delete in C++.

Which surprised me. And I recently ran another test between C++ and Java. Of course, it was very focused. It was just opening files, reading them in a line at a time, and then writing them out. And did it what I think the ideal way it is to do it in C++ and the ideal way it is to do it in Java. And it turned out that Java was at least on par, but in some cases significantly faster. Which surprised the heck out of me, because I just assumed that naturally it would be slower.

So maybe it really is possible to get it at least close enough to C++ that it doesn't really matter. And the fact that you can get a Java program up and running in maybe half to a third the time that it would take to get the equivalent C++ program up and running, that's where the real drama takes place. That's why people will move to it.

TNC: Now, of course, some people don't want a garbage collector, whether or not it's optimized and efficient. They want to be able to delete their own objects, to know exactly what's going on. And I guess some people coming from C++ or C wouldn't take that point of view.

BE: Well, yes. The lack of a destructor in Java is annoying at first. But I think having the garbage collector changes the way you're able to program. It actually changes the shape of the language.

For example, if you want to return an array from a method in C++, and the array isn't passed in to you, you'd have to create it on the heap and you'd have to return both the array and the size of the array. You'd have to make a little struct [to hold that information].

And you'd also have to assume that whoever was receiving it on the other end knew that they were responsible for cleaning it up. If somebody called the function without catching the return value, you'd end up with a memory leak. And the benefits are -- well, there's so many programs out there that are shipped with memory leaks or that don't get shipped because they can't find memory leaks, that I think it's a pretty hard argument to go against the benefits of that.

TNC: At the same time, many programmers close files and free up resources and clean up memory in the destructor. With the garbage collector, this habit is not as ingrained. So that's another danger.

BE: Well, it is. The garbage collector only releases memory. Originally, there was a method called finalize(). It's still in the language. In theory you could override it and do other cleanup. But finalize() is not called at a known time. It is called whenever the garbage collector comes on.

It turns out that finalize() never got called. It's hard to call it exactly a bug in the language. It should never have been put in. It was a misunderstanding on the part of the initial designers.

TNC: Bruce, I have to cut you here. We have to take a quick break. We'll be back on the Dr. Dobbs Technetcast.

(Commercial break)

TNC: Welcome back to the program. My name is Philippe Lourier. I'm talking today with Bruce Eckel, whose most recent book is "Thinking in Java," published by Prentice-Hall. Bruce's Web site is www.bruceEckel.com.

And, Bruce, this is our last segment. So I'd like to talk a bit about C++. Here's a question here from the chat room that will help us ease into the topic.

WhoDat asks, "Given Java's programmer productivity edge over C++ do you see Java to C++ translators as viable and desirable products?"

BE: Well, at least in the mid term I think that that would be a useful --

TNC: Do those products exist, by the way?

BE: I believe they do, and I'm only saying that because I ran a peer-to-peer session at the Software Development conference last fall in Washington, D.C. And that came up. Somebody said, "We have faster productivity, we can get the projects going in Java. And if we want the speed or something else that C++ might have to offer, then we use a Java to C++ translator."

And so, from that, I'm assuming they exist. It seems like there are issues that one would have to struggle with to make such a translator. But I believe they exist.

I probably wouldn't go about it that way. I would probably do as much as I could in Java and then, if there was something I needed to do in C++ then I would probably use the native methods. Because they have a nice connection to C++ now. Native methods in version 1.0 were a bit awkward and clunky. But the version 1.1 stuff is much more comfortable and it works a lot better, I think. It's easier to program.

So I would probably do that. I think they already have a strong enough coupling. And so you could get what you wanted out of C++ that way.

TNC: One of the most recent additions to C++ is the Standard Template Library. And I think you'll agree with me that the library really changes some fundamental aspects of C++.

One of the things it does is make C++ maybe a higher level language.

BE: Yes. The STL is huge. It's not huge in the sense of large, but it's huge in the sense of the impact that it has, and that's one of the reasons that I felt it was really necessary to rewrite "Thinking in C++". Now that I think about it, I'm close to putting the first version of that up on the Web.

TNC: But the STL is really a conceptual shift, also.

BE: Yes. The standard string library means that you can leave behind the quoted strings and all of the worry and hassle that you had with them. You combine that with the STL and you have something which just for text manipulation is very powerful, because you can create a vector of strings. You have something that will hold a file a line at a time in memory and you can manipulate it and all that.

The STL is really a set of collection classes, just like Java's 1.2 collection classes. You've got dictionaries -- maps, they call them -- and you have sets and vectors and lists and those sorts of things. And you also have a bunch of algorithms, which perform operations not only on all of these data types, but also on primitive types, like it will work with strings and arrays and stuff like that.

So the combination of those two things is that you have something that is a much more high level set of tools. So your programming then stops, finally, looking like C programming with stuff on top of it.

TNC: You can also hide pointers using iterators.

BE: Well, iterators are more than just a pointer hiding mechanism. They're really a fundamental concept in the STL.

The STL separates the concept of what particular container you're working on from the algorithm that's working on it. And you use an iterator to accomplish that. Iterators are actually a design pattern. You'll find it in the design patterns book because it's that important.

TNC: Actually, there's an entire chapter on patterns in your book. Why did you include that chapter?

BE: Because -- this happened to me and I suspect it happened to many people -- you finally understand polymorphism and what it's about and you think, "Oh, putting functions and data together into a single little package. That's what object-oriented programming is." And then you go around, that's your world.

You understand polymorphism and you're a three-year old with a hammer and everything should be polymorphism.

And then when you see design patterns, you realize, oh, polymorphism is just one way to solve this problem. And the problem is separating the things that change from the things that stay the same.

If you look through the Design Patterns book, you see a table, towards the beginning of the book, where the authors show the different types of patterns that you use to isolate the part that changes from the part that you want to be unaffected by that change.

And so it's really about trying to in some sense allow change, and yet let the rest of your system be stable. It isn't just about code maintenance, it's also about design. And it turns out you can end up with a very good design.

TNC: Is there a generic library for Jave? I know the answer is yes, because you also cover that in your book.

BE: The Java Generic Library was created by ObjectSpace. It is kind of an image. It was based strongly on the C++ Standard Template library design. Early on in C++ somebody also did that with the SmallTalk class library design and they ported it over to C++.

And with that lesson we learned that that approach didn't really work very well, because a library that's designed based on the structure of one language doesn't port all that well.

TNC: So how good is the Java generic library port from ObjectSpace?

BE: I mean, I think it's fine. But my preference is the new 1.2 collections libraries, which I think is something that a lot more people are going to be using.

The problem, I think, with the Java generic library is that it probably is more complex than it needs to be, and it does have some of the issues that are left over from C++.

If you are coming from the STL, I think it's probably easier to pick up initially. But I like the design of the new collections library in Java 1.2 a lot better, because it's simpler and it actually ends up doing more.

TNC: Let's take a few questions from the chat room here.

BE: Sure.

TNC: They're not related.

"Bruce mentioned that Java programs can extend themselves dynamically. Where in "Thinking in Java" is this covered?"

BE: I'd have to send you to the index. But basically it has to do with -- I think if you looked up run time type identification and --

TNC: Well, there's 1,100 pages, so...

BE: 1,100 pages. You know, I can't tell you the page off the top of my head, but I'm trying to think of what you might look up in the index.

TNC: Okay, WhoDat, go to the index.

A question from Ken. What resources can you recommend for new programmers that are starting with OO systems?

BE: Well, I guess it depends on what your background is. If you have a background, if you are a programmer at all, then that's usually who my audience is. There are a lot of books that teach you to program without any programming background.

TNC: Actually, you can go to some of the classics. They may be a little difficult at first, but just immerse yourself.

BE: Well, the one book I learned C programming from, was Jack Purdom's C Programming Guide. and I don't even know if it's out there.And for me, that was great. You know, I just really liked that.

TNC: Okay, Bruce, we only have a few seconds left. What are you working on now?

BE: Well, I'm mostly working on the second edition of the "Thinking in C++," which I'll be putting up on my Web site. There will also be a CD-ROM for that. But I'm also working on taking my lectures and turning them into multimedia so they can be both streamed over the Web and put onto CD-ROM.

So I'm basically looking at different ways to put out information.

TNC: I have to cut you off, Bruce. Thanks very much for being with us today.