Head First Java

honestpuck writes "Earlier this year I decided to learn Java. I'd spent some time using JavaScript without really getting my hands too dirty but I'd pushed it way to far and realized I needed a bigger hammer. Grabbing a copy of Learning Java, 2nd Edition from O'Reilly I started learning. First problem, I have to admit I've stayed away from object-oriented programming; after all, I've been writing software for nigh on twenty years without it - why make life hard? Sure, I understood the concepts and I'd done a little but never in a language so strongly committed to OO as Java." Read on for honestpuck's review of Head First Java, which he compares in style and content to Learning Java. Head First Java author Bert Bates, Kathy sierra pages 650 publisher O'Reilly rating 8 reviewer Tony Williams ISBN 0596004656 summary Good, offbeat Java tutorial with new approach to learning computer topics

The Good

Of course, you can't learn Java without a good understanding of object-oriented languages. I made fairly heavy going with 'Learning Java' until I decided to dive in head first. Head First Java, that is -- a new book from O'Reilly that has a totally different attitude to teaching than I've seen before in computer books. It also looks like this might be the start of a series from O'Reilly, the website an introduction seem to assume that there will be more 'Head First' titles and I hope so. The style is humorous, full of graphics, cartoons, puzzles, quizzes and crosswords. It reminds me of the textbooks that used to try and teach me geometry and algebra in high school or my daughter's elementary books on Roman and Greek history I purchased for her at the British Museum. The style didn't work to teach me much algebra and geometry, but I wasn't anywhere near as motivated. This time, it worked. In a couple of weeks I worked through the book and finally have Java skills where I can branch off and start coding the projects I had in mind (though something more advanced will be required soon.)

In the introduction the authors examine learning and explain why they designed the book as they did. To quote from one section: "Some of the Head First learning principles. Make it visual. Put the words within or near the graphics. Use a conversational and personalized style. Get the learner to think more deeply. Get -- and keep -- the reader's attention. Touch their emotions." They argue that our brain is tuned to novelty, and that their style provides the novelty to keep your brain turned on. They also provide ten tips for good learning. That's one thing that seems to set this book apart from most other computer books, they say they think of their reader as a learner and indeed that's the way you are treated by the book. You can start to get a feel for their ideas by visiting headfirst.oreilly.com, a site devoted to the series. You can also grab a couple of example chapters from the books web page, which also has the usual marketing info, table of contents and errata.

The Bad

When compared to Learning Java the coverage is not as good. Head First really only covers the basics, up to and including creating a GUI with SWING and then touches a number of others; Learning Java goes on to explore, with a fair depth, network programming, web programming, servlets, applets, Java Beans, XML and other topics that are only touched on briefly in Head First. If the style of learning does not suit you then this will be an incredibly irritating and useless book, I'd give it a try first, though. If it isn't for you then the style of Learning Java might be better.

Conclusion

When you get down to it, though, the only way to really decide on the worth of a tutorial is to decide how well it teaches. Head First Java excels at teaching. OK, I thought it was silly, I had a hard time making myself do the exercises, fill out the crosswords and solve the puzzles. Then I realized that I was thoroughly learning the topics as I went through the book. Learning Java was doing the same job, but the dry traditional method wasn't doing as well. Both books are well written, designed and constructed -- the style of Headfirst Java just made learning, well, easier.

It would seem to me that the 'Head First' approach is going to work wonderfully for the more 'beginner' topics, books for introducing you to a new style of programming, a new language or a radically different operating system or application. So if you're looking for a book to introduce you to Java then I can recommend Head First Java. Now if I could only find a book as good to introduce me to Common Lisp.

You can purchase Head First Java from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

EWD 696

[pheared]

In the introduction the authors examine learning and explain why they designed the book as they did. To quote from one section: "Some of the Head First learning principles. Make it visual. Put the words within or near the graphics.

"The habit of using pictorial aids, like any habit, is very difficult to get rid of. If, however, we take any responsibility for the effectiveness of our thinking habits, we should try to get rid of the habit as quickly as possibile, for it is a bad habit, confusing and misleading up to the point of being paralysing."

Re:EWD 696

[Anonymous Coward]

What is that a quote from? As a technical trainer we are taught that there are different types of learners and one of those types is visual. They learn best by seeing examples and graphics. That quote sounds like elitist bullshit that makes it seem like all learning should be done with dry imageless textbooks.

Re:EWD 696

[pheared]

http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD696. PDF

Re:EWD 696

[TheWanderingHermit]

"The habit of using pictorial aids, like any habit, is very difficult to get rid of. If, however, we take any responsibility for the effectiveness of our thinking habits, we should try to get rid of the habit as quickly as possibile, for it is a bad habit, confusing and misleading up to the point of being paralysing."

Anyone who would say that obviously has no knowledge of how people learn and how different people learn with different styles.

As someone who spent 10 years with learning disabled and emotionally disturbed students, I can say one of the most effective teaching aids for ANYONE is finding out how they learn and presenting material in the style in which they absorb it the best. Since I worked with those who had the most difficulty learning, I had to learn as much as possible about how we ALL -- disabled, "normal", or gifted learn.

In a nutshell, anyone who can make a statement like the one above is ignorant. It has the sound of someone who is so busy showing off how intelligent he or she is that he has yet to realize how little he knows about people.

Perhaps it was written by someone who does well with the style of learning he describes because he spends all his time in books and on the web and has not yet learned how to deal with the real world yet.

Re:EWD 696

[logpoacher]

Hi WanderingHermit,

It was written by Edsger Dijkstra (one of the most influential thinkers in software design). A great guy. Died last year, I think.

But he wasn't talking about teaching - he was talking about conceptualizing - in particular, about reasoning in software development and mathematics. He argued that visual design tools in programming made you focus on the thing that was made visible, (which is usually the easy bit), rather than the hoards of less visible possibilities, wherein lie bugs, limitations and assumptions.

He's probably right - although I know enough programmers who have problems expressing the basic requirements to suggest that a bit of vision can upgrade a hopeless programmer into a fairly hopeless one. It may be that his reasoning explains why visual programming tools have never replaced the text editor for anything other than very simple software development, just as graph plotters haven't replaced equations for mathematicians!

But this has nothing - much - to do with teaching or learning....well, judge for yourself, here's the original:

http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD696. PDF

To be honest, I don't think the parent post is relevant - the quote is selective and out of place. Interesting to be forced to become aware of that, though: it's a non-obvious subtlety about progression from novice to expert.

Cheers.

I await a review of...

[PHAEDRU5]

..."Mr Bunny's First Cup o' Java"

Re:JavaScript != Java

[Anonymous Coward]

!= means "Really really is equivalent to", right?

Misconception

[shaldannon]

It appears our reviewer has fallen under a common misconception.

Java != JavaScript

The two are not even related. Yes, you can use them together, but the only thing they have in common are the four letters "J-a-v-a". It's bad enough when normal people fall under this misconception. We don't need supposedly technically savvy people succumbing to the same thing.

JavaScript was developed by Netscape as a dynamic browser language, and "extended" by Microsoft. The W3C "standardized" it, and then both Netscape and Microsoft went about with their own proprietary versions.

Java is owned by Sun Microsystems and was originally an embedded systems language. Sun took the language, renamed it "Java", and added web functionality.

Re:Misconception

[Anonymous Coward]

It is almost like somebody saying - I wanted to study cartography because I already know something about cars.

Re:Misconception

[M-2]

The current W3C approved release of it is, I believe, currently referred to as ECMAScript, in an attempt to separate the two. (The ECMA is a European governing body on standards, and I do not recall what it stands for at this time).

I wouldn't mind seeing them separated like that - it would make more sense and minimize confusion, as well as the interleaving of books in bookstores. "Java... Javascript... hell, they must be the same thing!"

Re:Misconception

[Ranx]

The W3C "standardized" it, and then both Netscape and Microsoft went about with their own proprietary versions.

The W3C has not much to do with JavaScript.

ECMA is the organization who made JavaScript into an independent standard (ECMAScript).

Re:Misconception

[SweetAndSourJesus]

There could be a sort of natural progression there, though.

Maybe our reviewer was building, say, a Javascript-based navigation system for a website and decided to do it in Java to avoid cross-browser issues.

Oh, and the W3C never standardized JavaScript. ECMA did with ECMA-262.

Re:Misconception

[sokeeffe]

No, he has not fallen under any misconception.

His problem was that he found that he could not achieve what he wanted using a javascript (an arguably limited web-baed scripting language) and decided to move to another language with more powerful features.

Re:Misconception

[Waffle Iron]

Another misconception he seems to have is that JavaScript isn't object oriented. It actually uses an interesting object system that uses "prototypes" rather than classes. This system, while somewhat strange, is actually more flexible than a lot of class-based systems. (IIRC, one of the more extreme examples of a prototype-based language is "self". It's worth checking out if just to help you understand by counterexample exactly what's going on when you use classes in a normal OO langague.)

Re:Misconception

[HenryFlower]

They're not completely separate. I remember seeing Java objects being instanciated in JavaScript embedded in pages destined for Netscape.

Right, and by that logic Python is related to Java 'cause you can instantiate Java objects in Jython. And C is nearly the same as lotsa languages, 'cause lotsa languages have C extensions which allow you to instantiate C objects in the language. Javascript and Java have only the notion of being roughly C-looking languages which came out at roughly the same time, and were both championed by Netscape.

Re:Misconception

[haystor]

If you people would actually read the review its quite clear that he had outgrown JavaScript and was moving on to Java (Java being a bigger hammer than JavaScript).

He also never staid that JavaScript has not object system, just that he's never done much with objects. Thus he needed a good basis in how to programm OO, something you don't have to have to use JavaScript.

Re:Misconception

[Malc]

Instead of being a prick, you could have just reminded me that what I'm remembering is actually a feature of LiveConnect.

Don't know about Head First Java, but ...

[UTaimSRC]

The Java Cookbook is the way to go for beginners.

http://www.oreilly.com/catalog/javacook/

Re:Don't know about Head First Java, but ...

[BFKrew]

The Cookbook is a great little book, but it only really provides snippets of code and little examples of how to achieve basic tasks. It does not teach you about Java, about OOP, how to build programs or anything about the differences in things like Applications, Applets or Server Applications etc.

Re:I'd like to take this oppertunity..

[pheared]

How can Java be slow? It's a language. Languages typically can not be quantified by speed.

Implementations are a different story, however. What you mean to say is that in your non-benchmark toting experience, Sun's Java Runtime Environment, version 1.4.2 is slow. On this, I will agree.

You might want to investigate the other implementations of the JRE out there. IBM has one that is reportedly quite good. (Well, one person has told me it was worth it.) There is also Blackdown.

Regarding licensing, I also agree. It's muddy at best, and akin to selling your first born to Sun at worst. Depending on your vantage point, of course. ;)

Get the Tremendous books Free

[MarkWPiper]

I agree, Thinking in Java is a great book. Check it, and Bruce Eckel's other works out for free at:

mindview.net/Books

You'll be glad you did!

Try Thinking in Java 3rd Edition

[nih]

best book on java imo, and its free to try out
http://mindview.net/Books/DownloadSites

Re:Try Thinking in Java 3rd Edition

[crwfrd]

I too am a fan of Eckel's books. They emphasize the big picture that leads you to thinking in the language's "paradigm" while still fully covering the details.

It's true that Eckel's books are less than ideal as reference texts -- he's too conversational. But in introducing not only 1) the semantics of a language and 2) its syntax, his strength best lies in 3) teaching the way the language expresses programming design concepts -- helping the reader to appreciate that language's fundamental design patterns.

And of course, his books are FREE. What more could you ask for?

Re:Java is bad for our industry

[BFKrew]

Sorry, but I think you are wrong on this one.

There are a LOT of programmers out there with no experience of anything other than C, C++, Visual Basic, Perl etc etc. Just because students are taught Java and industry DEMANDED Java don't blame people for making a lot of money out of it!

Also, why should programming be hard? It shouldn't be. If I can find any tools, languages etc that make my job easier, quicker and less stressful I use them. And if I can be quicker it will be cheaper and if I am quicker and cheaper, I keep my job.

If my boss comes to me with a business problem and it can be solved in a day with Java, as opposed to a couple of days in Perl, VB or whatever then the business will make a decision to go with that.

I agree Sun won't get back it's R&D on Java, but I guess that MS with the .Net framework -will- make money from the Java R&D ;)

OOP for the procedural programmer

[djrisk]

I too had some problems w/understanding object-oriented programming. I was strong w/procedural languages, and your standard top-down programming style, but I struggled grasping the concepts of OOP.

I found "The Object-Oriented Thought Process" to be a great jumping-off point in helping me familiarize myself with how to think in-terms of OOP.

The intro to OOP chapters that are in most introductory books are OK, but they just didn't do enough for me.

Re:OOP for the procedural programmer

[Jucius Maximus]

"I too had some problems w/understanding object-oriented programming. I was strong w/procedural languages, and your standard top-down programming style, but I struggled grasping the concepts of OOP. I found "The Object-Oriented Thought Process" [amazon.com] to be a great jumping-off point in helping me familiarize myself with how to think in-terms of OOP."

If you're going to do Java, OOP is essential IMO.

I'm working on a project right now at work (in MSAccess VBA, ugh) where Java would be a godsend. Using overloaded constructors for objects, polymorphic programming and OO techniques would probably reduce the quantity of code for this project by a factor of 10.

So if you're learning java, make a point of learning how to build those basic abstractions like nodes, linked lists, stacks, queues, binary trees, AVL trees, etc as object oriented structures. IMO it's way easier than doing it in C with structs and pointers to the moon and back. (Don't get me wrong, C has its strong suits. For example you get to create a celebration dance to perform when you eliminate all memory leaks.) In the end, however, if you build the basic abstractions it will help you both in creating efficient alogrithms in all languages and in learning how OOP really should work.

The best way to learn Java...

[barcodez]

if you want to learn a particular Java aspect look at Sun Java Tutorials. (they are excellent a free).
If you want to leatn OO programming and Java I would suggest Think In Java (it's the best and it's free).

Re:The best way to learn Java...

[FortKnox]

I have to second the 'thinking in java' suggestion, by Bruce Eckels. I learned java by that book, even though I already knew OOP. If you want a good C++ book, "Thinking in C++" by the same guy is the way to go.

In fact, any book by Bruce Eckels is a great read. It reads like a book, and teaches you in easy terms. It isn't like reading a math book, which most programming books tend to do.

Re:I'd like to take this oppertunity..

[sahala]

You, sir are 100% correct.

I'm going to send a memo to the top 300 US companies (any index, take your pick) and inform them that all this time they were wrong about implementing business solutions in Java. Why? Because you (mallocchio) took the "oppertunity" to say that it "sux". Instead they should be using something light, like C, or maybe even assembly if they're hardcore enough. I mean, all these hundreds of corporations can't possibly be right. Their projects obviously have all failed because they used Java.

I mean the only reason Java is popular in the enterprise world is because of Sun's wonderful marketing department. Those sneaky bastard marketers ... they got the best of us. I mean they totally did their jedi mind trick on me -- I'm gonna have to cut off my head now because it's now known after your esteemed declaration that "Java sux".

P.S. I know you're trolling.

Common Lisp

[Lemmy Caution]

Now if I could only find a book as good to introduce me to Common Lisp.

What's wrong with the Paul Graham books on LISP? On Lisp can even be downloaded for free, and ANSI Common Lisp is a great introduction to the language.

Re:I'd like to take this oppertunity..

[wik]

Most modern JVMs compile Java bytecode to optimized native machine code. If you spend most of your execution time in your application (not the JVM), Java is quite competitive with C.

If you're interested in seeing how this really works, I'd suggest downloading the IBM Jikes RVM (Research Virtual Machine), which is a JVM/JIT compiler that is almost completely written in Java (it actually can recompile itself at runtime, in addition to your application). Since it's written to be a platform for compiler research, it's not the fastest JVM on the planet, but it has reasonably well-documented code and it certainly does what you described.

Best Series For Learning Java

[jyuter]

Has got to be the Core Java Series. Between the fundamentals and the advanced books, I haven't found anything as complete and as clear as this.

Re:Best Series For Learning Java

[JoeWalsh]

I'd tried Java back in the 1.1 days, but had no real use for the language at that time so I let it drop. Earlier this year, though, a project dropped in my lap that really needed what Java provides, so I started looking for good books on the subject. After browsing through the tremendous amount of Java books at my local bookstore, I settled on the Core Java series.

By reading the two volumes you mention, I was able to come up to speed quickly. In fact, I finished the project just one month after buying those books.

I highly recommend the Core Java series to anyone who wants to learn the Java programming language.

question...

[inkedmn]

am i the only one getting a distinct "for dummies" vibe off of this book?

no comment on the book itself, it's just that "head-first" seems like it could very easily be the next "complete idiot's guide"...

Viewing at level 5

[955301]

This is the first time I've tried to look at a story with 63 comments with my threshold set to 5, no comments showed up!

Somehow I knew though, when the article starts with I decided to learn Java because Javascript wasn't good enough., that there would be trouble!

Begun, the Javascript != Java flamewars have.

Re:Java is bad for our industry

[bmj]

The dot com years produced millions of Java "programmers" that did not how to do much beyond blindly mimicing the Sun "Pet Store" J2EE example without understanding the fundamental concepts that underpin the technology.

How many other languages can you fill in the blank with? VB? C# (soon?)? Perl?

Sure there are folks who "learned" Java and really don't understand it. And sure, most of them are out of work...but calling it a "glut" is a bit of an overstatement. Most of those people won't find work in the industry. And if you're good a programmer, and work for a good company, you're still making good money these days (at least where I live).

There's a huge glut of programmers on the market with little or no experience using any other programming language other than Java.

So what if that's the only language you know? If you're a good Java programmer, what's the problem? I know a couple guys who just graduated with degrees in computer engineering. They "learned" plenty of languages in 4 years, but they only know one language well enough to use it professionally -- either C or Java.

Tufte

[Tripp Lilley]

I beg to differ, and I'm not the only one:

Assessments of change, dynamics, and cause and effect are at the heart of thinking and explanation. To understand is to know what cause provokes what effect, by what means, at what rate. How then is such knowledge to be represented?

This book describes design strategies--the proper arrangement in space and time of images, words, and numbers--for presenting information about motion, process, mechanism, cause and effect. These strategies are found again and again in portrayals of explanations, quite independent of the particular substantive ocntent of display.

And we also enter the cognitive paradiese of explanation, a sparkling and exuberant world, intensely relevant to the design of information. Those who discover an explanation are often those who construct its representation. [...] All these quick-qitted creators and discoverers demonstrate methods by which to represent, describe, illustrate, and, indeed, construct knowledge.

Many of our examples suggest that clarity and excellence in thinking is very much like clarity and excellence in the display of data. When the principles of design replicate principles of thought, the act of arranging information becomes an act of insight.

[...]

The idea is to make designs that enhance the richness, complexity, resolution, dimensionality, and clarity of the content. By extending the visual capacities of paper, video, and computer screen, we are able to extend the depth of our own knowledge and experience. [...]

-- Edward R. Tufte, Visual Explanations (Introduction)

Learning Java

[StarCat76]

I read O'Reilly's Learning Java (1st Edition) and really liked the way the book is written. Its no-bs way of shwoing the concepts is useful for beginners who want to learn the structure of the language, and for experts, who use it as a reference for the advanced concepts. All in all, I'd recommend it thoroughly. -Neil

it's inevitably necessary to have simpler books

[192939495969798999]

I saw some 6-year old kids talking the other day. Kid 1: Have you seen my website lately? Kid 2: no. Kid 1: It has a new layout now. Kid 2: cool!
It's only a matter of time before these kids will want to learn JAVA, and a basic, picture-laden book is sure to attract their attention quicker than a tome that they probably can't even lift.

Re:I'd like to take this oppertunity..

[mydigitalself]

well considering you opted for the coward route, how is anyone going to take you up on that one!

plus, i entirely disagree with you, i have php applications that pull data from mysql faster than an equivalent java application.

the JAVA advantages, for me, are:
- OO through and through
- scalability in the form of J2EE
- well writen java is a pleasure to read and understand
- cross-platform
- fantastic package library and 3rd party packages
- sun screwed up and gave it away!

Re:I'd like to take this oppertunity..

[sahala]

I do suppose I could actually work, too....

Shut the hell up! You don't see anyone else "working" do you? Stop being so damn selfish and get back to posting.

Re:I'd like to take this oppertunity..

[955301]

I'd like to take this opportunity to point you to IBM's SWT if you still think Java is slow as a client side app.

Just because Swing got into a politically driven quagmire, doesn't mean the language or runtime itself is hosed.

It's just a matter of your choice of libraries.

Java tutorial anyone?

[cpn2000]

When I first learnt Java (6 years ago ... JDK 1.0.2), I went with the Java tutorial. Considering that there were not too many books written on the subject at the time that was not a hard choice to make.

My verdict is that the tutorial is not a bad way to learn Java programming at all. The trick is to read every line (dont skip anything), and try every example in there, and in addition try your own variations. Worked for me, but needless to add ... your mileage may vary

Them Java Coders

[inertia187]

About them Java Coders,
codin' here and there.
Just like Gosling's Keynote said,
Java's Everywhere!
Them platform neutral Java Coders,
runnin' hotspot mode.
Keep them classes nice and neat,
'til it turns bytecode.
Multi-threaded Runnables,
and Serialization,
keeps those members all in line,
avoiding race condition.
How to be a Java Coder,
here's thee easy way:
Go to sun.com's web site
and get the SDK.

Re:Java is bad for our industry

[forgetmenot]

Java is just an OO-Language so I don't see how you can say it is "bad" for the industry. And personally, I get tired of seeing the same negative criticism being leveled time and time again as if the thing has never progressed in the last 5 years. I work with Java everyday and have watched it improved dramatically with each new release. But I'm meandering..back to the original point. Java is just a language. Your effectiveness with Java is only as good as your understaning of the OO principles that it is built upon, and THAT is where I see problems. It sounds like what you're really biting at is that you've seen a lot of people, rushed into the market, who *surprise surprise* can't code their way out if a paper bag. How is that Java's fault? Are you suggesting they would have been better programmers had they been rushed through C++ instead? Dot com boom/bust had nothing to do with Java. If you want to blame anyone, blame the VCs. They're the ones who spoon fed money into dumb projects creating the market for overpaid poorly trained programmers in the first place. The fact many of them may have learned Java is beside the point.

As far as good or bad for the industry... well.. you don't really define what your industry is. Software house for the most part don't use Java. I personally feel it's an "IT" language, and the IT shops/people that I've been involved with LOVE Java for its productivity and cross-platform compatibility.

Re:Stay away from it.....

[botzi]

This is far, far, too far away from being the best book on Java.

I'll even argue that this is not a good book at all. As always Mr. Eckel is going on and on with a 2-3 pages of reflections and a small piece of programming practices(everyone who've tried to read the C++ thinking, know for what I'me talking about), so my point is :

1) The book will be confusing for a beginner programmer.

2) It'll be useless for the most part to a person with some general programming culture.

Anyway, the best book to start with java is "On to Java", I don't even remember the authors but it's everything: Short, explicit and well structured. A problem may be that it should be a bit outdated.......

Of course, all one really need to start programming in Java is here

Learning the language is one thing...

[fmedio]

... but achieving clean, efficient object-oriented design is another one.

Transforming the buzzwords of "encapsulation", "reusability", "modularity" into workable and efficient solutions requires way more work than strictly learning the language.

Also, a common pitfall is to believe that you can do whatever because some garbage collector is taking care of memory management.

Before even reading whatever about java, I'd strongly recommend :

- of course, Design Patterns, by Erich Gamma et al;

- Principles of Object-Oriented Software Design, by Anton Eliëns (online version here).

Re:I'd like to take this oppertunity..

[The Mayor]

On the J2EE side, they also make extensive use of object pooling (for servlets, DB connections, etc etc). This makes Java on the server-side much faster than naive implementations written in native languages (for the record, ASP is a naive implementation, whereas ASP.NET is not....ASP.NET is able to handle similar loads to JSP/Servlet solutions, whereas ASP is about 5x-10x slower).

Throw in dynamic runtime optimizations offered by HotSpot-type JITs and you end up with a server-side solution that bests most other solutions in terms of speed. Server-side Java is quite nice.

Take a look at the Resin web server/servlet engine, if you're interested in seeing how good server-side Java can be. This thing can serve static content faster than Apache!

Well, to be pedantic about it...

[PHAEDRU5]

!"JavaScript".equals("Java")

OO techniques are seldom fully understood

[boster]

The majority of developers do NOT fully understand OO principles. There is a difference between learning the syntax and the basic features and understanding how to leverage them. Most OO developers can write and use simple classes, use inheritance and basic polymorphism. This is generally all that is taught in courses and language books. This is also sufficient to get most things done. :) However, most people this level of knowledge do not understand just how much more can be done. A good example of more powerful OO programming is in the Gang of Four book. The conceptual leap from procedural to basic OO programming is but the first step. I guess what I'm getting at is that once you're at this point where you're using basic OO techniques, then there's still a lot more you can learn (even if you know each and every language feature and its syntax). Just be aware of that and look into it someday.

Re: OO techniques are seldom fully understood

[gidds]

Very true. OO isn't just a way of programming, it's a way of thinking about problem-solving and about complex systems. Java's good for it not just because it has a good implementation of OO principles, but also because the (huge) standard library is generally well thought out, and some parts are a masterclass in good OO design. Using it introduces you to some powerful OO techniques, and encourages you to use them yourself.

My way of thinking about objects is to consider them as little people. Each person has a job to do, and does it single-mindedly; but they're simple folk, and so you should never give them more to think about or remember than they need to do their jobs. Each one should be a good team member: they should be polite to the other objects, do exactly what they say they will, as efficiently as they can, tidy up after themselves, be as quiet as possible, and not get in the other objects' way.

This analogy may look strange, but it seems to work for me! Especially when it comes to decomposing a problem into objects and determining their roles and responsibilities. When coding, I just think "If I was this object, what would I do? What would I need to know to do it? How should I communicate with the other objects around me?"

Re:I'd like to take this oppertunity..

[TheLastUser]

You can do a static compile of java into machine dependant bytecode using gcj if you are into that.

I do a lot of server side Java and I have never had a speed issue. Its much more likely to be a database issue that slows up the app than the execution of actual byte code. Remember that web/app servers ALWAYS top out on io before cpu anyway, so the fact that the Java server is running at, say, 40% cpu instead of 20% doesn't mean a heck of a lot.

For your next book...

[RevMike]

I highly recommend Design Patterns Java Workbook by John Metsker as your second Java/OO book. It also takes an "interactive" approach to learning, developing a number of key GoF patterns in Java.This book is a practical way to learn not just Java syntax, but real design skills in Java.

After that read Java Development With Ant by Hatcher and Loughran for good info about how to set up real java development environments. Ant is a tool that fits a similar ecological niche as make, but has tons of extra features particularly useful to Java developers.

Oh, and don't bother with an ide. Real men use vim.

Languages versus Programming

[FreshFunk510]

"I've been writing software for nigh on twenty years without it - why make life hard? "

I think there is a distinction here that needs to be brought up that I feel many programmers are unaware of. This is aimed for programmers who decided to go out there and learn Java who have never learned an OO language.

I think the goal of programmers should be to learn to code well. Having said that, those who then go on to "learn how to program java" from an instructional book are a bit mistaken in my humble opinion. There is a big distinction between language, which is a tool, and theory. The above analogy would be best explained by saying that you would want to learn how to write good stories and then picking up a bit on the english language. Good stories can be written in any language, pick one. It is the same for programming. Learning a language won't teach you to program well, it will just teach you to program in a different language.

Why learn OO? Let me take the analogy further: scripting languages really only allow you to write short stories. They do things similar to OO programming, but the scope of their use is quite limited and when you attempt to take them out of that realm they become difficult to use and unwieldy. An OO language allows you to write novels. They allow you to program larger programs, with a better underlying structure and more complexity.

Writing Learning Java...

[patniemeyer]

Hi, I'm Pat Niemeyer, the author of Learning Java. As I sat down this morning to begin work on the fifth edition of the book for Java 1.5 I was
pleasantly surprised to see this item on Slashdot (my first stop of the day). So I thought I'd chime in with a little bit about what it's been like working on this book over the years and ask for you help in making it better.

The short story is that trying to authoritatively cover a topic as broad as the Java language and libraries and to do so without simply producing a giant shelf-filling reference tome or dry as toast text book is a very difficult challenge. I think there are parts of the book that have met this challenge and parts that can be better in the future.

Now, I consider myself to be a relatively funny and creative person (also sexy, and other adjectives as well) and I think if someone had asked me back in 1995 what my first book would have been like I might have imagined something a bit lighter and breezier than an 800 page book about a programming language. But I think that the Slashdot audience in particular will appreciate that despite its size and some obligatory coverage, this is a book written by someone who has a passion for software and architecture and that I have tried to pour my creativity and time into crafting elegant, insightful, and *minimalist* examples. I wrote this book for people who think and learn the way that I do and that may not appeal to everyone.

I think the strongest parts of the book are in the most exciting and difficult areas of Java - topics such as advanced networking, multi-threaded
programming, and XML. IMHO Learning Java's coverage of these topics is deeper than some single topic books in their entirety.

The Java language is a moving target and one that gets more moving parts every day. The greatest challenge in writing about it now is not what to cover, but what to leave out. I have spent many many hours on the phone with my editor (Mike Loukides) over the years debating about what we need to include and what we need to cut. In recent editions which have included a CD in the jacket (yah, I know... book CDs are normally useless) I have started moving the old, less relevant material (such as some of the original AWT API stuff) to the CD.

I have also experimented with the introductory tutorial chapter - trying to give a broad overview of the whole language in one chapter before diving into details. Some people may see that and be turned off. I hope they'll dig a little deeper.

I am very interested in what Slashdot readers have to say about how to make the book better. Your comments would be very well timed right now as I am updating the book for Java 1.5 as we speak.

I hope you'll check out my book if you need to learn (or learn more about) Java. If you have already mastered Java then I hope you'll buy a copy of my book and give it to a homeless person ;);)

Thanks,
Pat Niemeyer
Author of Learning Java, O'Reilly & Associates and the BeanShell Java scripting language (www.beanshell.org).

Online docs

[Hard_Code]

Don't forget that Sun has a excellent set of Java tutorials online for free:

Tutorials & Short Courses

These are essentially the contents of the Sun press line of books.

Strongly committed to OO? Java?

[stesch]

You must be joking. Please take a look at Smalltalk or Ruby before talking about OO.

Yes!

[Hawkins]

I received this book just last week and am slowly working my way through it in-between work and other projects. I and am very pleased with it. The reviewer is correct in that this book makes learning much, much easier. It is, however, a little short on in-depth material, but I feel it can be forgiven for that in light of how well it teaches the basics.

How well does it teach? Through 4 years of a comp-sci degree that taught things using C++, I never understood Object-Oriented design as well as I do after just the first 7 chapters of this book. Hell, I'd recommend the entire book just for the chapter on polymorhism alone.

I won't go into detail since I'm short on time, but basically, if you're new to Java but know how to program in some procedural language already, this book might be what helps you go from writing programs the same way in Java to writing in Java, the way it was designed to be used. If you already know Java, though, you'll probably be bored silly. It's not a reference tome.

Eckels' Books are Downloadable

[goodviking]

Here here to the Bruce Eckels sugesstion. He is far and away one of the best authors on the topic of OOP. Further, he does a lot of training, etc... and has made most/all of his books freely downloadable.

Richard Feynman might not agree!

[logpoacher]

Good try - but Dijkstra wasn't talking about education, he was talking about abstraction. Remember his example? - where he mentions drawing an "abstract triangle", and how as soon as you have drawn a specific triangle, then you have made concrete decisions: "does it have an obtuse angle" etc. Dijkstra's point is that when you represent a general concept using a specific example, you get blinded to the possibilities offered by alternative examples. And he's right - to a certain degree.

You see, the counter to this is Richard Feynman. Do you recall in "Surely You're Joking?" when he mentions how he'd try to understand mathematicians by visualizing everything they said? "Take a set (a ball) - disjoint (two balls) - and then add hair, slice them up etc etc". I've used that technique ever since I read about it when I'm following arguments, and it works a beaut. It worked for him, because the mathematicians had probably not got their heads out of the equations to look at what they were doing.

So I think visualization is great (or even essential) for following a line of a complex argument or learning a technique - and that's where diagrams come in. However, unless your visualization is a perfect representation of the thing you're learning, it won't instruct you much about where the process *doesn't* work (unless it fails for your chosen example!). For instance, you won't find many pictures that can show you a nice OO class relationship, whilst simultaneously telling you much about *inappropriate* relationships.

In programming, mathematics, and any other "reason-oriented" activity, it's these negative cases that catch you out: the exception cases and unexpected inputs, the accidental divisions by zero - in short, the assumptions that you build in because you're focusing about the one way it should work, not the ways it won't. And so in practice, good experienced programmers need to clear their mind to see what they've written, not what they *think* they've written, and that, I think is Dijkstra's point.

But it's not got a lot to do with learning a new craft. And that's why good teaching books have good diagrams and plenty of manageable, relevant examples.

BTW - a good case of what Dijkstra is talking about is shown in the ancient search for the truth behind Euclid's 5th Postulate - where people got bogged down for centuries because they thought that the LINES and POINTS in geometry had to correspond to lines and points on a flat surface - plane geometry. But as soon as they abstracted it and stopped visualizing it, and treated LINE and POINT as abstract entities which simply obeyed the Rules, it gave rise to spherical and hyperbolic geometry. "Godel, Escher, Bach" tells the tale nicely!

I never get sick of hearing that...

[the-build-chicken]

I decided to learn Java. I'd spent some time using JavaScript

ok...they're really nothing alike, except for the word 'java'. By the way, if you want to learn anything java, why waste cash on books...just head over to java.sun.com and go through their doco section...they have full documentation on almost every api, and have been keeping it up to date for as long as I can remember (the java trail is an excellent peice of work)

Dijkstra wouldn't like the LingerieExceptions...

[I'm Just An Object]

Or the girl in the bathtub, or, well, about 98% of what's in a Head First book. And this was deliberate. I'm the co-perpetrator, and creator of the Head First series.

Personally, and as smart as he is...Dijkstra is just not someone I would have ever wanted to date, or even sit next to at a dinner party.

And wasn't he also the author of something to the effect of, "Anthropomorphizing is the sign of an immature mind?"

Well, we blew that one Big Time. I think half the book is anthropomorphized *things* -- objects, variables, threads, you name it, we've turned it into a living breathing (sometimes swearing) thinking *feeling* creature.

We'd like to counter Dijkstra with someone we feel certain would kick his ass in a celebrity boxing match. Roger Schank. He was chairman of the computer science dept at Yale (and director of the artificial intelligence project). Last I heard he was Distinguished Professor of Computer Science at Carnegie Mellon University. (OK, as far as the boxing thing goes, Schank does have the advantage of being alive...)

And since we know some people will be misled by the pictures into thinking that it must be a "for the lesser mind" , or that, "if it's that fun, it must not be serious." we can point to some heavy hitters who have endorsed the book (on the cover) . One is a former PARC guru and now the Director of User Sciences and Experience Research at IBM Almaden Research Center. He also teaches advanced studies in artificial intelligence at Stanford.

Another is Ken Arnold, co-author with James Gosling of "The Java Programming Language", and a co-developer of the Jini specification.

Then again, another quote inside the book is from Rick Rockwell, the original groom from "Who Wants To Marry A Millionaire" (now Darva Conger's ex.).

PARC and FOX in the same endorsement page...

That alone will stop some folks from getting it.
And if you don't like the style, it won't even be tolerable -- at best, an acquired taste, whereas a more traditional format is usually acceptable even if you don't LOVE it.

So a lot of folks (me especially) are wondering how many people out there will actually *want* to learn this way. This is a brand new concept, so we'll have to see. If you want to know how it's being received, check on Amazon from time to time, and search on Java, and sort on bestsellers, or check the O'Reilly bestseller list. The book has been out for only a few weeks; it will be up to learners/readers to decide.

I can tell you our proudest moment came when we got an email from a guy whose wife doesn't fully approve of him reading the book.

cheers,
Kathy Sierra, co-author Head First Java

Re:I'd like to take this oppertunity..

[swillden]

I think the point is often made, at least in C++ circles, that a mandated GC in standard C++ would be non-real-time, because a real-time GC has worse average performance (like you said) and is very OS-dependent.

Were such a thing to be mandated in C++, I suspect the standard would simply specify the APIs and semantics without touching on performance, just as they do with new/delete and malloc/free. However, I don't think making GC part of standard C++ would be a good idea, anyway. The language isn't well suited to GC, mainly because the programmer can play all kinds of pointer tricks, which means that any GC for C++ must be conservative (has to assume that any pattern of bits that might be a pointer *is* a pointer) and non-copying (meaning it's not allowed to move stuff around in memory, because tracking down and updating all of the references would be slow and error-prone).

I think GC is a useful add-on to C++, though, and it's not really necessary to make it part of the standard for it to work. The relatively small performance degradation you're likely to get from a conservative, non-copying collector vs. malloc/free is often well worth the savings in programmer effort and the increase in reliability.

I'm not sure you could implement a real-time GC for current Linux 2.4 for example. It would require kernel support, and so it is fair to compare malloc/free vs. non-real-time GC because that is realistically what developers would face.

I don't think there's any difference between GC and malloc/free in that regard. Kernel support isn't necessary at all for GC, although I have to wonder if there's anything that could usefully be done... Normally, though, a GC-based system requests large chunks of memory from the OS (via sbrk(), etc.) and then parcels it out as needed, just like malloc does. This is a good thing performance-wise in both cases -- switching to kernel mode for every memory allocation would be tremendously expensive.

Anyway, if you need hard real-time guarantees on Linux, you'd better get a Linux patched up for real-time, and you'd better use a real-time memory manager, whether malloc/free or GC.

Even on 64-bit architectures? Even with lots of allocations (hand-written lists, etc)? I guess it's possible but non-trivial, and a search is always at least O(log N), right?

I can't really see why a 64-bit architecture would matter at all. In fact, I'd think a conservative GC would end up being less conservative, since the space of potentially valid pointers would be such a small fraction of the total 64-bit space.

As to the cost of a search... in the worst case I think it's linear with respect to stack size + size of reachable heap objects. In practice, however, people have come up with all sorts of really clever ways to reduce the effort required. I'm no expert on this (though I have a casual interest that used to motivate me to read papers), so I can't really describe the techniques. There's some good information here.

One that I think is cool, though, is generational copying collection. Basically, it exploits the fact that most objects are allocated and then die very quickly, with only a few being retained "long-term". So, what they do is allocate all new objects in a "young object" pool. When a GC happens, they move all of the objects that are still live into another pool and then just mark the entire "young object" pool as free. You can see how this makes allocation and deallocation of short-lived objects very, very cheap, since the young object pool has no real structure -- just a pointer that indicates where the free space begins; allocation always grabs memory from there, with no worries about finding a block large enough, or updating lists or flag bits or anything. The copying is a bit of overhead on the deallocation side, of course, but it's usually dominated by the savings of not having to examine all of those individual chunks, update free l