Beginning Java Objects

A few weeks ago, reviewer honestpuck looked at Head First Java , comparing it to O'Reilly's Learning Java, 2nd Edition. Now wcbrown writes with a review that starts on the other foot; he reviews Beginning Java Objects: From Concepts to Code in comparison with Head First Java. Read on for his review. Beginning Java Objects: From Concepts to Code author Jacquie Barker pages 688 publisher APress rating 8 reviewer Bill Brown ISBN 1590591461 summary This introduction to Java centers around a single application and follows it through from concept to modeling to development.

Coming to Java from ColdFusion and ASP has been a long and arduous journey. Those languages lack the strong typing, the formal structure, and the incredible power that Java offers. In the course of grappling with concepts completely foreign to those languages, I have purchased and read many books. I've read Thinking in Java, Java: How to Program, and Java in a Nutshell, all in a futile effort to learn the language in a systematic and useful way. Each book came up short in the teaching department: one covered Java too abstractly, another too concretely. Reading these books' turgid style was a surefire turn-off to the language. After a while, I realized that the problem wasn't totally with me -- that these books were not designed for newcomers to the language.

I then came across two books that changed my view of Java introductory texts completely. Both Beginning Java Objects (hereafter BJO) and Head First Java (hereafter HFJ) take beginner-centric approaches to instruction. They both seem to understand that reading computer language overviews is a necessary evil and that most books fail to connect with their readers. They both take active roles in guiding the reader through Java, though their executions are wildly different.

Two Different Styles The fundamental difference between the two books is teaching style: they're both obviously the products of serious pedagogical thought. BJO's pedagogical considerations are understated, while HFJ's are explicit and pronounced. BJO moves the reader from start to finish on a single project, introducing Java syntax and language elements as needed and largely in the final third of the book. HFJ, on the other hand, divides major topics into smaller units interspersed with pictures, diagrams, and tables in order to break up the monotony.

The effect of BJO is that each chapter builds on the previous one, thus discouraging browsing through the book haphazardly. This was the first computer book that I have read cover-to-cover, though it took me forever to get through at over 650 pages. It starts with an introduction to objects and object-oriented programming. This first section gets you thinking about the concept of objects, gradually working in the seeds of the book's example project, so that you're thinking about what objects you'll eventually need. The second part involves modeling those objects you deemed necessary in the first part using UML. It's by no means a complete guide to UML, but the author wants you to realize that UML is a vital part of the design phase.

The final part introduces the majority of Java syntax and focuses on implementing those objects you've modeled. First, the author works on a command-line version of a university registration system using the file system to persist data. Finally, she implements a GUI version using Swing that still uses the file system.

HFJ, on the other hand, reads like a computer book version of Alton Brown's cooking show Good Eats. Syntax lessons share the pages with funny anecdotes, cartoonish diagrams, silly exercises, and sidebars of various kinds. Some of the jokes and visual aids will make you groan, but they are, by and large, helpful and not too lighthearted. At first, the style seems like a gimmick but you quickly lose that sense of novelty. The book is organized around 17 topics that the authors think are important. Each chapter only marginally builds on the previous, so skipping around is both possible and suggested. The topics range from the common (objects, polymorphism) to the rare (RMI, sockets, exceptions). There's also an appendix that covers briefly 10 items that didn't quite make the cut for the book but were too important to leave out entirely. If I had to characterize HFJ's teaching style, I would describe it as visual.

Which is Better? So they have different styles, which one should you buy? I think that if you have to choose one or the other, you need to evaluate your learning style. Think back to when you learned your last language or important subject. How did you learn it? Did you systematically follow a tutorial? Or did you come up with an application and learn what you needed as you needed it? I would describe the first method as a hierarchical learning style and the second as a visual learning style. There's much more cognitive psychology here that would better inform such casual definition, but that's beyond this review.

For the hierarchical or systematic learner, BJO is the book for you. The author's presentation of an application from start to finish is very well done and the application actually bears a striking resemblance to something that would exist in the real world. The introduction of UML to the design process will warm the cockles of a systematic learner's heart. What's more, the natural progression from one topic to the next will help those learners who need structure and rigor in their instruction. HFJ might strike this type of learner as cutesy and flighty. While it's definitely a more soporific read, you really have a sense that you're learning from every paragraph and page.

The visual learner would probably not get very far into BJO because there's little code to read or practice with until the third part of the book. HFJ is perfect for this type of reader since it encourages flitting about while it entertains your brain into learning. The topics aren't covered as thoroughly as in other books, but that's because the authors are trying to present only what's necessary in order to avoid cranial overload. The book's breezy style makes for very easy reading and I more than once found myself eager with the anticipation I normally reserve for fiction of the page-turner variety. In addition, the book covers some topics, like exception handling, that I hadn't encountered in my introductory Java book adventures and it does so in a very compelling and memorable way. There is an application that is developed over the course of the book, but it's not as well integrated into the book as the one in BJO is. Unlike BJO, this book sometimes leaves you unsure of why you're learning a particular item until later. Often, though, these lapses are addressed in a sidebar they call "There are no dumb questions," but I would have preferred to see more of them.

Anything Left? Neither book, though, is perfect. For example, both books whizzed through some subjects that really deserve more treatment: exception handling in BJO and variable types in HFJ. Also, neither discussed persistence beyond the file system. In the real world, I have a feeling that file-based persistence is one of the least common varieties. I can understand, though, that dealing with JDBC and the like would have increased the lengths of the books as well as their complexity. Finally, neither book did a good job of telling the reader what the next steps in learning Java should be. Java is a huge topic and it is very confusing for the beginner to get a bearing in the Java ocean. Having an expert say "If you're interested in JSP, you should find books on these subjects next, and then these" is of inestimable benefit. Heck, it's even hard to know what areas of Java you might be interested in if your introduction to Java is casual and not demanded by work needs.

BJO omits any mention of unit testing your applications, but I think that's largely a shortcoming of having published the book in 2000. HFJ revels in test-driven development and includes writing a test as the second step of the three-part development process. Each code sample includes a test class and the authors stress repeatedly the importance of TDD. Unfortunately, they don't mention JUnita, glaring omission since the two are practically synonymous. Tests are emphasized but the reader isn't shown how to use them effectively. With the value attendant in a test-first development process, these omissions are of serious concern.

Concluding Thoughts These two books combined make for a very solid introduction to Java. Though they take different tacks, I think the categorization of people's learning style into a simple dichotomy is not realistic. People learn through a variety of means, yes, but often that variety is present in an individual. Reading both books will ensure that your learning style is covered as well as reinforcing the basic principles of good Java programming through repetition. There really isn't enough overlap between the two books to make the reading of them both tedious.

Once you've read these two books (or just one if you're a cheapskate), you should probably consider moving on to Bruce Eckel's Thinking in Java and perhaps finding a good book on JDBC or Java and XML. Eckel's book covers much of the same ground as these two, but there are some sections in his book that you absolutely must read to progress as a Java programmer (or learn them on your own, of course). Where you go after that is up to you and I would recommend a quick survey of the topics at prominent Java Web sites to see what sort of areas are available.

You can purchase Beginning Java Objects: From Concepts to Code 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

cheaper

[SHEENmaster]

If you're REALLY a cheapskate, you'll convince all of your friends to learn Java. A month later, you'll have every "24 hours", "21 days", "for dummies", etc book ever written about the language.

Re:cheaper

[fishybell]

If you're REALLY a cheapskate, you'll convince all of your friends to learn Java. A month later, you'll have every "24 hours", "21 days", "for dummies", etc book ever written about the language.

Unfortunately when you do receive and read those books you'll be no better at Java than you were before.

Both books?

[fishybell]

Once you've read these two books (or just one if you're a cheapskate)

Being the cheapskate that I am, I would hope that either book would be sufficient to learn a programming language's syntax, nuances, etc. Unless I've never programmed before and expect to learn to be an professional level programmer in Java, one book should be enough to cover my needs.

Re:dont like java

[v_1matst]

er... Java -does- come with a compiler: javac.
It comes with the SDK... javac == java compiler... It compiles into byte code which the virtual machine then handles for whatever platform you are on. There are other specifics obviously, but that is the general idea. Perl and the like however do -not- have compilers as they are an interpreted language... and therefore have interpreters...

Learning Style is Key

[fbg_satan]

Looks like it all depends on if you are more of a visual learner or if you learn more from having hands on the code.

Re:Learning Style is Key

[CaptainTap]

Agreed, personally I don't learn much unless I'm looking at unformatted binary.

oreily nutshells

[514x0r]

any of the nutshell books are horrible to learn from--though i find them invaluable as reference and count 4 behind me right now.

funny alton brown ref.

Re:oreily nutshells

[psxndc]

4? Just 4? How did you even find out about slashdot, marketing-guy? I have 7 behind me, and this is just my work collection. I have about the same at home. I tell ya, geeks these days. In my day, we had EVERY nutshell book, multiple copies and multiple versions. You didn't know if it was 2nd edition or 1st. That's the way it was and we liked it. We _loved_ it!

psxndc

Re:oreily nutshells

[tundog]

I have 2, C++ and Java in a Nutshell. Really, what else does a code Guru need?

Re:oreily nutshells

[514x0r]

linux in a nutshell.

i hate to admit it, but here--at work--i have ASP in a nutshell.damn i feel dirty.

Re:oreily nutshells

[ninthwave]

I borrow a persons at works ASP in a nutshell when I need it and my work has a shower for when you get that dirty feeling. But worse yet at home I have Delphi in a nutshell. Though I am began to use safari at O'reily and find it a good way to use reference in work scenario's. Get the reference you need for the project and smile as no one can laugh at your bookshelf they see behind you, only keep the linux, java, c, c++ and php books there leave asp, windows and Domino books hidden online.

Re:oreily nutshells

[ninthwave]

English in the above post was affected by a lager and a defect in my construct, my apologies.

Re:oreily nutshells

[tcopeland]

I had the "ASP in a Nutshell" book in a previous job. It was very useful - the floor in my office sagged a bit, so I put the book on the floor under my bookcase to keep it level. It was the perfect size and served me well for over a year in that capacity.

Re:oreily nutshells

[pokeyburro]

Oddly, Java in a Nutshell is exactly where I learned Java. For that matter, I learned Perl from an O'Reilly book as well. I enjoyed the process a lot, and consider myself really good at both (well, proportional to the amount of time I spend programming in each).

By that time, however, I had learned a dozen or so major languages already, so that may have helped. Once you've learned BASIC, Pascal, C, LISP, Prolog, and some assembly language, picking up any other programming language is quite painless. When I finally get around to learning Python, I could probably pull it off of Egyptian hieroglyphics with little trouble.

Re:oreily nutshells

[Anonymous Coward]

I learned Perl pretty much from the Camel book. I don't learn very well when I'm lead by the hand; I prefer the reference style mixed with language basics.

Re:oreily nutshells

[jmccay]

No kidding! Who reads a book that has in a nutshell in the title? There are not many nuts that are big. The analogy obvious means there is just enough information to remind you. In other words, you need to already know it!
Am I the only one who sits down to browse through a book before I buy it? Especially when I am expecting to learn the language from it?

I don't know about that

[Anonymous Coward]

...the incredible power that Java offers...

I have been programming Java for about two years, and did not receive any incredible powers. You can make your computer do a bunch of stuff, but most of it is pretty lame and deals with either printing the text or displaying some images. However, Java failed to deliver the promise of being able to walk on water, fly high into the sky, pass through walls and understand any language without an interpreter.

I am switching to .NET.

Re:I don't know about that

[damballah]

What other spectacular non-existent features made you switch .NET?

Re:I don't know about that

[MojoMonkey]

Dude, just:

import christ.jesus.*;

there is the new one:

import matrix.neo.*;

but it's just now catching on.

Re:I don't know about that

[Anonymous Coward]

Cool. I've always favored switching to YAL that won't deliver. But hey, I believe there are no upgrades -- only side-grades where you exchange (some of?) the bugs you know for ones you don't.
If the language trivially did all you wanted it to do, then there would be no need for a programmer. Then the IT department of most companies would be much shallower --- your PHB's B would be doing everything in a VB sort of pointy-clicky interface, only since the language is omniscient it woud do the right thing. Will .NET do that ... I think .NOT

Re:I don't know about that

[nother_nix_hacker]

understand any language without an interpreter

No, it always been one language but the VM is needed I'm afraid.

Re:I don't know about that

[Anonymous Coward]

I am switching to .NET.

Thus achieving nothing except (the ever aptly named) Windoze lockin.

Congratulations!

(I think you'd have been better off trying flying off a nearby skyscraper...it might work, and either way you'll be happier in the long run!)

Re:I don't know about that

[The Wookie]

Really, if you had done any work with Java at all, you would see that you do indeed have these powers..

walk on water...
Take your bloated code and use it as floats for your feet - you're walking on water

fly high into the sky
Stand on top of the heap and start your program - you'll be high in the air in no time.

pass through walls
Java uses pass-by-value, so you must convert yourself into something of value. I recommend having your face printed on currency and then slip yourself through a seam in the drywall. I don't recommend using dollars, however, since the $$$'s make it look like you're using Perl

understand any language without an interpreter
This comes up in every Java-related thread on here. Early Java was interpreted, but now we have Just-In-Time compilers, not to mention traditional compilers like gcj.

Re:I don't know about that

[stratjakt]

don't recommend using dollars, however, since the $$$'s make it look like you're using Perl

The dollar sign ($) appears nowhere on a dollar bill (or any denomination).

Re:I don't know about that

[Anonymous Coward]

I have been programming Java for about two years, and did not receive any incredible powers. You can make your computer do a bunch of stuff, but most of it is pretty lame and deals with either printing the text or displaying some images. However, Java failed to deliver the promise of being able to walk on water, fly high into the sky, pass through walls and understand any language without an interpreter.

Dude, maybe you just need to update your JVM.

Java has given me the power to avoid dish-pan hands after washing dishes, crawl up walls, teleport (however, I do leave a strong stench of brimstone in my wake, beggars can't be choosers) and 'throw' my farts so someone else always gets blamed! Like, maybe I should become a super-hero dude or something?!

Re:I don't know about that

[Anonymous Coward]

.Net is such a joke . We have switched to Java since it is stable scalabale and mature products. .Net is buggy and full of holes.

Re:why

[Anonymous Coward]

The USAF uses java for several of its apps.

Re:why

[fishybell]

Java is for idiots.

Who uses Java?
Nobody, that's who. Sun paid off some schools to force students to learn it, and even with that brainwashing, nobody uses it.

Now I'm sad. Not only did I have to pay for tuition that Sun was supposedly paying for me, but I also got brainwashed into being an idiot nobody. I think I'll go cry now.

Exceptions

[CraigoFL]

The topics range from the common (objects, polymorphism) to the rare (RMI, sockets, exceptions).
[rant]
Exceptions are one of the more fundamental (and useful) features of the Java language. Whether or not they are "in your face" (as far as source code is concerned), they exist and have the potential to greatly change the flow of your program. Considering them "rare" is a tremendous disservice to those learning how to use Java in a productive manner. I hope that this is simply the reviewer's choice of language, and not a flaw in the book iteslf.
[/rant]

Re:Exceptions

[wcbrown]

I know how important exceptions are. If you read the review, I noted how refreshing it was that HFJ actually offered an entire chapter dedicated to it.

Rare and common, in the context, meant rare and common among Java books. That's all I meant.

Re:Exceptions

[Osty]

Exceptions are one of the more fundamental (and useful) features of the Java language. Whether or not they are "in your face" (as far as source code is concerned), they exist and have the potential to greatly change the flow of your program. Considering them "rare" is a tremendous disservice to those learning how to use Java in a productive manner. I hope that this is simply the reviewer's choice of language, and not a flaw in the book iteslf.

The problem with exceptions is that they're not so exceptional anymore. Think about it. The name implies that an exception is something that shouldn't have happened (you ran out of memory, a parameter was bad, something just totally blew up). That doesn't mean that you tried to open a file that doesn't exist -- that's not an exceptional case for a filesystem-handling object, because it happens all the time. Exceptions should be used as error handling, and nothing more. If you can clean up after an exception and try again or continue on, great. Otherwise, you should be showing/logging a useful error and bailing out. You certainly should not be basing program flow on exceptions.

I agree that exceptions are a fundamental part of Java and other languages, and they should definitely be covered by any good Java book, but any book that covers exceptions should take the time to teach the user how not to use them as well as how to use them.

Re:Exceptions

[MojoMonkey]

Trying to open an stream to a file that doesn't exist is exceptional, because the app should have checked this before attempting to open the stream.

You certainly should not be basing program flow on exceptions.

Agreed, and Java in no way promotes this practice. Unfortunately, lazy programmers see this as an easy way out to pull crap like you mentioned regarding the file stream.

I agree that exceptions are a fundamental part of Java and other languages, and they should definitely be covered by any good Java book, but any book that covers exceptions should take the time to teach the user how not to use them as well as how to use them.

hmmm that was the point I was going to make... I just realized you are taking the same stance as me...

in that case, ME TOO!

Re:Exceptions

[clary]

The problem with exceptions is that they're not so exceptional anymore. Think about it. The name implies that an exception is something that shouldn't have happened (you ran out of memory, a parameter was bad, something just totally blew up). That doesn't mean that you tried to open a file that doesn't exist -- that's not an exceptional case for a filesystem-handling object, because it happens all the time. Exceptions should be used as error handling, and nothing more. If you can clean up after an exception and try again or continue on, great. Otherwise, you should be showing/logging a useful error and bailing out. You certainly should not be basing program flow on exceptions.

Ah, but in practice, exceptions are used for just such not-so-exceptional circumstances. This is not a choice that can be made by Java applications programmers since a bajillion Java API classes work this way.

One could argue that this is a good thing, that checking for things like file not found in a catch block instead of checking return values inline can lead to cleaner code.

The Java API defines java.lang.Error (and to some extent java.lang.RuntimeException) for those "real" error cases, those cases that might require logging an error and bailing out.

I'd be interested in anyone's favorite references on when it is better to report non-success status in return codes, and when it is better to throw an exception. That is a class design issue that comes up all the time.

Re:Exceptions

[CraigoFL]

The name implies that an exception is something that shouldn't have happened (you ran out of memory, a parameter was bad, something just totally blew up).

Well, you can (and I will) make the arguement that Java has a slightly finer-grained approach to what you just described. In addition to the class Exception, there's also the class Error, and both implement the same interface Throwable.

IMO, the names are appropriate. An Exception means that a method encountered a condition that it can't express in terms of its return value (thank god we don't have to deal with all those result-structs of C/C++). We generally associate this with "bad", but really it doesn't have to mean anything other than "out of the ordinary". An Error takes one step closer to "bad" with it's harsh-sounding name.

Note that, in your examples, the running out of memory condition causes an OutOfMemoryError, not an Exception.

The issue becomes recoverability; an application could probably recover nicely from a FileNotFoundException (perhaps by creating a new file and continuing on merrily?). However, most apps (more specifically, their programmers) wouldn't have any idea what to do if they ran out of memory; hence, you generally don't catch Error, even though it's possible to do so.

I agree that exceptions are a fundamental part of Java and other languages, and they should definitely be covered by any good Java book, but any book that covers exceptions should take the time to teach the user how not to use them as well as how to use them.

I agree with your agreement. :-P Too many tutorials gloss over them. They are very powerful and make a programmer so much more productive, but yet aren't really all that complicated. I'm usually "disappointed" (to borrow a recent cliche) to see how often they're considered a specialty feature.

FYI, here's some javadoc links:
java.lang.Exception
java.lang.Error

Re:Exceptions

[Osty]

Ah, but in practice, exceptions are used for just such not-so-exceptional circumstances. This is not a choice that can be made by Java applications programmers since a bajillion Java API classes work this way.
One could argue that this is a good thing, that checking for things like file not found in a catch block instead of checking return values inline can lead to cleaner code.

If Java forces you into using non-exceptional exceptions and using exceptions for program flow, then Java is poorly designed (I'll admit that I haven't used Java in some four years, though I have been using C# for the past 6 months and I've not yet run into a scenario in C# that requires me to handle an exception for a non-exceptional error case). And as far as making the code cleaner, I disagree. The extra syntax you need to handle an exception is clutter, and can put significant space between the error handling code and the code that caused the exception, making the flow harder to follow. Most importantly, however, exceptions are expensive. In C++, for example, an exception costs you around 1000 processor cycles. Compare that to two or three cycles to check a return value, and you'll see why exceptions should only be used for exceptional cases. Java and C# may handle exceptions differently so that they're not as costly, but they'll still be more costly than a simple comparison and jump.

You may think I'm splitting hairs, but you'll notice a marked performance increase if you rewrite your code to use normal flow control constructs to control the flow of your code, rather than using exceptions.

I'd be interested in anyone's favorite references on when it is better to report non-success status in return codes, and when it is better to throw an exception. That is a class design issue that comes up all the time.

I don't have any references, just this rule of thumb: If an error is unexpected, then it's exceptional and should be handled with an exception. If it's an expected error, then it should be handled with a return code. To go back to the example of opening a non-existent file that I used in my original post, it's pretty obvious that a file not existing is non-exceptional (now, if the file that's missing is a critical config file that your application requires and can't generate on the fly, you should throw an exception, but the library method to open a file stream should not). What has been done before is to provide two methods. One checks the existence of a file, and will return true or false, and the other opens a stream and throws an exception if the file's not there. In that scenario, you really should check for the file's existence before opening the stream. Personally, I wouldn't write a method in that manner, preferring to return an error code if opening the stream failed so that it's not necessary for the user to make an existence check first.

Re:Exceptions

[Trak]

throw java.lang.URADorkException

Re:Exceptions

[gfody]

You certainly should not be basing program flow on exceptions.

I tend to agree, but if you read ms's best practices around .net and web application design you would be suprised at how exceptions are working their way into common flow. Even for something as trivial as an authenticate method "token = authenticate(username,password)" they would rather you throw an exception if the password was invalid instead of a return code. In the end the flow does seem somewhat better..

try
{
token = authenticate(...);
dosomething(token);
}
catch(loginexception)
{
msgbox("invalid login");
}
catch(otherexception)
{
....

Re:Exceptions

[2short]

A generally excelent discussion of why exceptions are nice, but I can't let this go by:

"thank god we don't have to deal with all those result-structs of C/C++"

C++ had exceptions & try/catch blocks many years before Java existed.

Re:Exceptions

[CraigoFL]

Trying to open an stream to a file that doesn't exist is exceptional, because the app should have checked this before attempting to open the stream.

Allow me to disagree with this (and explain why). I believe that this line of thinking is just a throwback to the C/C++ days, when there wasn't any other way to do it.

So, you want to open up a stream... that's something along the lines of:

File foo = new File( "foo" );
FileReader reader = new FileReader( foo );

Now, what you're suggesting would go something like this:

File foo = new File( "foo" );
if ( foo.exists() ){
FileReader reader = new FileReader( foo );
} else {
System.out.println( "File is missing dammit" );
}

However, the FileReader constructor must declares that it throws a FileNotFoundException.. there's no way to force the programmer to check if the file exists beforehand. So you have to wrap in try/catch (or declare the exception in the calling method of course):

try
{
File foo = new File( "foo" );
if ( foo.exists() ){
FileReader reader = new FileReader( foo );
} else {
System.out.println( "File is missing dammit" );
}
}
catch ( FileNotFoundException e ){
// This now is (probably) impossible-to-reach code.
// What should we do here if this happens anyway?
// Probably the same thing we did before.
System.out.println( "File is missing dammit" );
}

So now you have a redundant check to see if the file exists (remember, whatever check happens in FileReader's constructor still happens). In addition, the check in File.exists() doesn't necessarily duplicate the check in FileReader(). If FileReader() does some additional (and desireable) checking that File.exists() doesn't, then the call to exists() is truly superfluous and maybe even dangerous (especially if you're dealing with multiple threads).

Instead, I like to do this:

try {
File foo = new File( "foo" );
FileReader reader = new FileReader( foo );
} catch ( FileNotFoundException e ) {
System.out.println( "File is missing dammit" );
}

This way, there's only one check. Not only do you get the performance gain (which may or may not be trivial), but you also don't have to re-do your error handling code.

I believe that, with the proper care (which isn't that difficult to have with the right training), exceptions can be used to control program flow and increase code readability. Of course, this can be abused too, just like anything else.

Re:Exceptions

[2short]

I'd say that's a perfect example of where exceptions are apropriate. You have a simple function (authenticate) that returns a simple value. If it can't return that simple value, it needs to alert the caller, and pass back an entirely different type of information.

Also, if the code that knows what to do if that exception occurs is several levels up the call stack or a several blocks scopes out, you don't need to write code at every level checking for the error and passing it along.

Re:Exceptions

[CraigoFL]

I'm no C++ expert, but IIRC C++ exceptions were a non-standard language enhancement available only to certain compilers. Please enlighten me if I'm wrong. :-)

Regardless, I think exceptions are a good thing, in Java, in C++, in C#, and even in VB.NET of all places. Accept no substitutes!

Re:Exceptions

[MojoMonkey]

Great! You are entirely correct, I hadn't thought it all the way through. Thanks for that.

Re:Exceptions

[Javagator]

Early versions of C++ did not have exceptions, but exceptions are now part of the ANSI standard. Java exceptions are modeled somewhat after C++ exceptions except that Java throws an exception object, while C++ can throw any type/object.

Re:Exceptions

[Javagator]

I'd be interested in anyone's favorite references on when it is better to report non-success status in return codes, and when it is better to throw an exception. That is a class design issue that comes up all the time.

It depends on how "exceptional" the circumstances are. For example, if a "file not found" condition is unexpected and requires error recovery, then it should be handled as an exception. If it is something that can occasionally happen during the normal flow of events, then the programmer should check for the existence of the file before trying to open it.

Re:Exceptions

[amoe]

the programmer should check for the existence of the file before trying to open it

And code a classic race condition? No thanks.

Re:Exceptions

[Electrum]

What has been done before is to provide two methods. One checks the existence of a file, and will return true or false, and the other opens a stream and throws an exception if the file's not there. In that scenario, you really should check for the file's existence before opening the stream.

That method is completely wrong. It contains a race condition: the file can be deleted or renamed after it is checked but before it is opened.

Re:Exceptions

[Javagator]

If only one thread is accessing the file, then having it deleted between checking and opening should be handled with an exception. If multiple threads are creating, deleting and accessing files (not the best design) then I would prefer using synchronization through a shared resource rather than using exceptions.

Re:Exceptions

[2short]

IIRC:
They weren't in the ultra-super-early compilers. They were added almost imediately by every copiler vendor worth mentioning, and were in just about the first draft of the standard. The standard commitee took basically forever hammering out other obscure details, so C++ wasn't an official ANSI standard until recently.
So if you're talking the accepted standard, everything was non-standard until a year or two ago. If you're talking the draft and/or de-facto standard, you were right 20 years ago...

I'm not sure anything can be a good thing in VB, since it being in VB implies the existance of VB...

Re:Exceptions

[Osty]

That method is completely wrong. It contains a race condition: the file can be deleted or renamed after it is checked but before it is opened.

I didn't say it was right, just that it had been done. And of course you can use locking methods to mitigate the race condition, though by doing so it's unclear whether it's still a better approach than just catching the exception, performance-wise.

Re:Exceptions

[BlueRibbon]

But would that guarantee that another program hasn't deleted the file?

Re:Exceptions

[Electrum]

I didn't say it was right, just that it had been done.

True.

And of course you can use locking methods to mitigate the race condition

Nope. Locking can only be done on an open file. See flock(2) and fcntl(2).

Re:Exceptions

[Osty]

Nope. Locking can only be done on an open file. See flock(2) and fcntl(2).

Oops. My fault :) I was thinking more along the lines of a critsec or mutex to avoid cross-thread race conditions, and it totally slipped my mind we were talking about the filesystem. Hehe. Anyway, I was advocating not writing your code this way, unless you can't avoid it. However, I'm not sure it's too big of an issue. You'll still need to catch exceptions on the filestream open call anyway, in case something else fails, and the race condition of finding the file there but having it removed before you can open it would truly be an exceptional issue. My main concern is using the exception as flow control. By checking for existence first, you'll know if you shouldn't even bother with the call to open the file. If you think the file is there and it turns out it's not, that's an exception. If you think the file isn't there and it turns out it is, your rectification code is where that should be handled.

Re:Exceptions

[jeremyp]

Except that the authenticate function should be in its own try block so that the code that handles the failed authentication stays near it

e.g

try
{
authenticate ()
}
catch (AuthException e)
{ /* Log in the security log + tell the user */
return ;
} /* do other stuff which might be several pages long */

Too many beginner books?

[Osty]

The problem I've generally had with books about programming languages is that they almost invariably start out with several chapters (anywhere from one to five) dedicated to concepts that either you should already know, or that you should learn elsewhere. If I have a library of 50 computer books, I only want one book that covers object oriented programming concepts, for example. I don't need nor do I want all 50 to cover OOP. Even if I only have a library of 5 books, I'd still rather have only one that covers the basics. That way, I don't have to dig through five different, sometimes conflicting, explanations of the same concepts. Rather than dedicating the first 200 pages of a 600 page book to that and selling for $50, they should cut those pages and sell the 400 page book for $30.

Yes, I understand that beginners need books too, but even they don't need a discourse on object oriented programming every time they buy a Java, C++, or C# book. Why can't we have one or two definitive books covering basics, and get rid of that stuff in the rest of the books?

Re:Too many beginner books?

[wcbrown]

If I had to speculate, I'd say that it was because every author thinks they bring a fresh and clearer perspective on OOP that they have to share with their readers. Or it's filler to bulk up the book. Choose based on your level of cynicism.

Re:Too many beginner books?

[stratjakt]

I'd say its because theres still millions of newbies out there who still think they'll become fabulously wealthy, just as soon as they learn how to program a computer.

That and once a programmer gets sufficiently advanced, their need for dead tree references diminishes to nothing. I know I rarely use any references, except maybe for the odd syntactical thing that I'll forget. (the "how do you call strncpy again?" type things)

It's not like I've nothing left to learn, it's that anything I learn from here on in will be through experience and doing.

I'm past the "this is what a stream and a class and an object is" stage, which is the real learning curve.

Re:Too many beginner books?

[kmak]

I agree. I recommend the "Language A for Language B programmer" books for this reason.. if you're already familiar with one language, you usually don't have too much troubling learning a new one... one example is this: on amazon..

Re:Too many beginner books?

[I8TheWorm]

A buddy of mine who is a published author once told me that publishers demand a thick book that "advertises itself" on the bookshelf. Many "fluffy" chapters are added for that reason, much to the dismay of the original author(s).

Re:Too many beginner books?

[scrotch]

I think it's because each author believes he/she is writing the One book you will need to begin. As in: "Why would you have 5 other books on the subject when this one is the only one you need?" They're then obligated to start at the very beginning.

It might be interesting for O'Reilly or another publisher (some entity above the Author level) to produce an "Intro to Procedural Programming" and "Intro to OOP" and similar set of books. So that when you wanted to learn something from O'Reilly books, you'd by the $15 Intro book and the $25 Learning book. Like you'd get "Intro to Proceduaral Code" and "Learning C" or "Intro OOP" and "Learning Java" or "Learning C++" instead of one $40 book with redundant information. The Learning books could assume you had the general concepts from the Intro books and just deal with the language specific implementations.

That's a lot of writing for a relatively simple idea. It's like yours, except at the Publisher level. The publisher might be able to assume the responsibility (ie: risk) for a reader to buy two books instead of one.

Re:Too many beginner books?

[Jucius Maximus]

"I'd say its because theres still millions of newbies out there who still think they'll become fabulously wealthy, just as soon as they learn how to program a computer."

I have to agree with you on that. Someone figured out they'd be fabulously wealthy if they harnessed the collective ignorance of the people who only want to get into programming for the perceived money.

This is how you get those people in CS courses who are obviously not cut out for it. Back in first year I was writing this quiz in a CS class. (It was a 20 minute in-lab quiz where you had to program the answer in Java.) I read the question in 2 minutes and programmed the answer in 30 seconds. The person next to me sat there uncomfortably and at the end told her friend she had forgotten how to program a loop. Probably wan't a stupid person ... just not destined to be a programmer.

I remember in this one senior C++ programming course in high school, during the first week, these two people came up to the teacher (who was this cool Czechoslovakian 'hacker-guy' that looked like the lead singer of Hansen btw) ask asked him if it was a "programming-heavy" course. Heh. Obviously they dropped.

It's people like this who drive the demand for the bazar of intro programming books. Maybe some dot-bombed slashdotters ought to get together and write one of these fantastic books and become wealthy ;-)

Re:Too many beginner books?

[nilenico]

Ah, well - it's better than having too few.

Back in the day (i.e 5 years ago), when I started out with Java, there were only those horrid "Teach yourself Java in 21 days", or even worse, "24 hours", books around. At least that I could get my hands on so that I could learn the basics of Java by the end of the week.
Java was still very much the Next Big Thing, expected to Save the World, and "everyone" thought it was just for web-programming and applets, and though we were mad when we started using it for a large CORBA-based middleware project (J2EE and EJB wasn't invented yet).

Luckily for me, I had at least learnt my OOP properly (my university used Simula at the time - go Simula!), so it only took a few days with the "21 days" book, but I would dearly have loved something else...

Of course these days, having mastered Java, all one needs is Javadoc.
Never mind the pros and cons of the actual language, Javadoc is truly a Good Thing when it comes to sharing APIs etc. within a project team. What ever would we have done without it?

Anyone can learn Java

[DavidNWelton]

If they can do it, so can you:

http://www.newtechusa.com/PPI/talent.asp

Rare Exceptions

[k-hell]

The topics range from the common (objects, polymorphism) to the rare (RMI, sockets, exceptions).

I think it's a understatement to call exceptions 'rare' though. It's an important part of Java, but may be difficult to fully master. At least in my programs, exceptions are far from rare! ;-)

I don't really care for Java.

[Anonymous Coward]

I'm more of a green tea person, myself.

Re:dont like java

[necio_online]

This is not longer true. You can compile perl code.

perldoc perlcompile

Re:why

[Sutekh-Acolyte]

Sun has assets left?

What If You're a C++ Developer?

[puppetman]

If you're a C or C++ developer, you probably won't need either of these books - Eckel's Thinking In Java will probably do you just fine, and you can download it for free.

Re:What If You're a C++ Developer?

[wcbrown]

Good point. I am neither a C or C++ developer and TIJ assumed a little too much background for me.

Re:What If You're a C++ Developer?

[Doppler00]

Eckel's books are pretty good. The books don't bother trying to be a language reference or "for dummies" books. Thinking in Java is very easy to read and follow but yes, having some background in another language helps to understand this book. I taught myself Java in about two weeks just reading through the chapters and trying to solve some of the problems at the end of each one. I learned much more from this book than any coarse I had in Java in college.

Re:What If You're a C++ Developer?

[tuxathon]

This is slightly unrelated, but do you know of a book designed for Java programmers moving to C++?

Re:What If You're a C++ Developer?

[puppetman]

This looks interesting:

http://www.amazon.com/exec/obidos/tg/detail/-/02 01 612461/102-3787245-0027333?vi=glance

Just googled "C++ for java developers"

Slightly unrelated question

[Anonymous Coward]

Slightly unrelated question:

I have been writing C# for a while, and would like to get a handle on Java so that I can tap into its larger job market. Can anyone reccomend a good book that can get to the point quickly? I read Core Java over a year ago, but I'm not looking for all of the nuts and bolts anymore. Most books out there go from Java *to* C#, not the other way around.

Re:Slightly unrelated question

[chef_raekwon]

Most books out there go from Java *to* C#, not the other way around.

buddy, all you have to do is read this book from finish to start...and you will have the desired effect....

Well, goodbye then...

[conan_albrecht]

most of it is pretty lame and deals with either printing the text or displaying some images.

If this is all you did with Java, you missed its real strength: server-side frameworks. Yes, Java didn't deliver on the client side. But it is excellent on the server side, with frameworks such as Tapestry, Struts, Servlets, J2EE (JBoss). It will be a while before .Net matures in these areas as Java has.

Personally, I've switched to Python for a lot of work, but for team-based enterprise development, Java is the best thing out there. It forces the weaker programmers to follow good programming concepts (such as forced catching of exceptions).

Re:Well, goodbye then...

[AKAImBatman]

Yes, Java didn't deliver on the client side.

I don't know about that. I think that there just isn't enough work put into the GUI by most people. Creating a *nice* GUI is HARD, no matter what system you're using. Macs make it a bit easier with the philosophy that every window should be as simple as possible. However, Windows (the standard most software strives for) strives to cram as many buttons and controls in as small of a space as possible. Under Windows, your program needs toolbars, drop down menus, side bars, dockable sub -windows, MDI frames, etc. That's a lot of work! None the less, there are some good examples of Java clients that can meet that standard. Here are a few links:

jGoodies, masters of the Java GUI
DataDino, my own Java based commercial product.
SmartCVS, a multi-platform CVS GUI.

Re:Well, goodbye then...

[MSBob]

My favourite is actually JProfiler. Very slick and speedy swing based UI (screenshot) oh, and a really darn good profiler!

Re:Well, goodbye then...

[oniony]

follow good programming concepts (such as forced catching of exceptions)

It's arguable whether this is actually good practice. Neither C++ nor C# have the concept of checked exceptions and, after programming Java for many years, I've been toying in my head with the merits myself.

At the very least, I think that the checked exception baseclass should be a sub-class of the unchecked exception rather than the other way around like it is in Java (RuntimeException=unchecked is subclass of Exception=checked).

Slashbot book review

[rkz]

This one is a great addition to the book shelf, you all know how to do certain things Java Objects but this book clarifies nicely why you are actually doing it. Also, it introduces nice advanced Java Object concepts which hardcore OOers might not have come across before.

Some Prices for the interested

[camilita]

Barnes and noble: $35.99
Amazon: $31.49

Java is easy - except it isn't

[RevMike]

If wcbrown thought that most Java books are tough on the beginner, he'll be in even worse straits in the J2EE world.

The Java language itself is fairly sparse. The collection of libraries that make up the JRE (Java Runtime Environment) is immense. And java is pretty useless until you learn your way around the APIs.

I like the language in general. The exception handling model is good. The standard APIs are rich. The namespace issues are handled well.

Developing in Java is a pain in the ass, however, due to classpath and packaging issues. The various IDEs help somewhat, but they can also obscure these issues and prevent you from learning them. In addition, everyone knows that vi is the one true editor - and vim provides good syntax highlighting too.

Best advice to a budding java developer is learn to use apache Ant right from the start. Using JUnit early on is also a good idea. Doing small projects with Ant and Java is far easier and more informative than doing projects in java alone or in an IDE.

Re:Java is easy - except it isn't

[wcbrown]

That's good advice. That's the thing I liked most about HFJ: the test-driven development emphasis. Why they didn't get into JUnit is beyond me.

Re:Java is easy - except it isn't

[mark_lybarger]

he'll be in even worse straits in the J2EE world.

i've always wondered why most companies don't throw a few college grads with a few VB and sql class under their belt twords a J2EE project.

Andrew Huard misappropriates personal information

[Anonymous Coward]

Damn it takes a long time to read that.
Support the GNAA!
Brought to you by the AAHAA (The Anti Andrew Huard Association of America)

Re:why

[el-spectre]

That's not too bad... I got brainwashed so bad that I think I've been paid for over a year doing Java work...

Re:why

[Anonymous Coward]

Yeah, only little nobodies like my employer: GM.

Dumbass.

Re:Odd

[Anonymous Coward]

Andrew? is that you?

Hey bud

[Anonymous Coward]

I think the guy you replied to was joking... Relax.

Hardly (In)credible

[game]

> the strong typing, the formal structure, and
> the incredible power that Java offers. In the
> course of grappling with concepts completely
> foreign to those languages, I have purchased
> and read many books.

Incredible powers with ducktape on C(++)? I guess it depends on the direction one's coming from. I came from the direction of C++ and python and I would never describe java as powerful. IMHO, it's a blockish, rigid, boring language with many libraries.

Discovering Common Lisp didn't help me fall in love with java, either. I also lost a lot of respect for static typing recently, gets in the way, and my tests are better at catching errors.

[That said ML's approach to this (static type checking, but no explicit type declarations) is nice.]

OT Jython with JBoss

[slithytove]

have you done it? Is it sweet? Any pointers?
What I'm actually working on doing, if you care, is wrapping an app called dcm4jboss in jython, but I'm still trying to get dcm4jboss working the way I want. I know python and c++ (along with some others) and have read and made small changes to java. From my jython book it looks pretty damn easy.

Re:OT Jython with JBoss

[thedave]

No! There are no pointers in java!

Re:For Christ's sake

[Anonymous Coward]

prepare my dinner - Kitchen
make my bed - Bedroom
bear my children - Bedroom
keep the house clean - OK maybe you are right but, outside of the house, useless

Re:dont like java

[oroshana]

That's still "byte code", which means it's still interpretted not "compiled" in the traditional sense. There are to-native compilers for Java, but their results are not by any means as fast as programs written in C++.

Re:Some Prices for the interested -- bookpool

[Anonymous Coward]

www.bookpool.com $30.50

Re:why

[Anonymous Coward]

Nobody, that's who

who's nobody? I guess that would mean everyone uses it.. egg on your face! haha

Re:For Christ's sake

[Anonymous Coward]

Believe it or not, there could be women reading slashdot because (surprise!) there are women programmers too. The fact is that half the comments posted have to do with guys being patronizing. Yeah, I'm gonna sound like a feminazi but hey, I'm a programmer and I read slashdot but it's comments like these which remind me why there are practically no other women into computers.

Then again, instead of seeing that as detracting from the possible good ideas and innovations that could be created or at the very least the understanding of a new slice of the market (which could be 50% if more software, advertising, etc was targetted at them), you probably see this as an opportunity for you to hopefully be one of the few that doesn't loose your job. Sigh. Sorry to sound exasperated. It could be that I am just overworked right now.

On To Java

[Anonymous Coward]

I would recommend "On To Java," instead. Easy to read, well documented, short lessons and with all the basic good stuff needed to become a JavaHead!

honestpuck sucks

[Anonymous Coward]

come on, seriously now.

Just Java

[Anonymous Coward]

There's a lot to be said for "Just Java" as an introduction, along with robocode, etc. IBM's Developerworks has a lot of helpful articles ranging from intro to advanced. What I've learned of Java has been from these sources & some of the books mentioned in the review. "Thinking in Java" is excellent.

Re:why

[Anonymous Coward]

I'm happy to be an idiot as long as I get to use Java! :-) Ahh, Java.

Ducktape?

[Anonymous Coward]

I realize people are taught to spell by sounding out words, but isn't "ducktape" just a little too much?

Re:Ducktape?

[TheShadow]

The problem is that most people pronounce that word incorrectly. Actually, it's duct tape. Two words. Why? Because it's _tape_, that is used on heating and air-conditioning _duct_ work.

Re:Ducktape?

[Skip Head]

Actually, It's Duck Tape.

Re:Ducktape?

[Anonymous Coward]

Because it's _tape_, that is used on heating and air-conditioning _duct_ work.

Not in the real world, bucko.

Re:Ducktape?

[game]

Skip Head, you have saved me from the Spelling Commando. Hereby, I promote you to be my friend. Hell, I would be your fan, if I could figure that one out :-).

At least I escaped the wrath of Grammar Nazi.

Re:dont like java

[AKAImBatman]

"Byte code" is simply machine instructions that your machine can't run. So it is compiled. Native compilation happens at runtime, but is a pretty transparent process since byte code -> native is a pretty straight-forward process. Java hasn't been interpreted in over 6 years.

Java is easy - except it isn't-Libraries.

[Anonymous Coward]

"The Java language itself is fairly sparse. The collection of libraries that make up the JRE (Java Runtime Environment) is immense. And java is pretty useless until you learn your way around the APIs."

Isn't this true of all languages? The power, and usage of C++ is in the libraries. The power of Smalltalk is in the libraries. The power of English is at the library.

"Developing in Java is a pain in the ass, however, due to classpath and packaging issues. The various IDEs help somewhat, but they can also obscure these issues and prevent you from learning them. In addition, everyone knows that vi is the one true editor - and vim provides good syntax highlighting too."

Isn't it the job of a good IDE to take care of such niggling details, as classpath, and packaging?

"Best advice to a budding java developer is learn to use apache Ant right from the start. Using JUnit early on is also a good idea. Doing small projects with Ant and Java is far easier and more informative than doing projects in java alone or in an IDE."

Noted: What do you think of Wrox "Beginning Java 2"?

Re:Java is easy - except it isn't-Libraries.

[bigchrissd]

Perl is amazingly useful even without the libraries.

For the cash strapped...

[ClippyHater]

BestBookBuys shows buy.com selling it for $27.60.

From newbie to J2EE

[Anonymous Coward]

You can go from knowing nothing about Java to programming J2EE systems by following this plan (I'm serious):

1. Read Beginning Java Objects. I agree with just about everything the reviewer says about this book. It's very well-written for people who've never programmed using OO before (but not for people who've never programmed in procedural), and in fact isn't even really a Java-specific book until the last third of the book. It's a great way to learn the concepts and terminology, which are all-important in the OO world.
2. Read Thinking in Java by Bruce Eckel. BJO is a great book to get the basic ideas down, and TIJ is a little too advanced for the complete newb -- but TIJ will teach you the rest of the language, the things that BJO leaves out. Also, the latest edition of TIJ does go into test-driven development.
3. Learn how to use the Ant build tool. Whether you do this from a book (Java Development with Ant is excellent) or from online tutorials, Ant will spare you much agony and will keep you from becoming overly addicted to a particular IDE's build conveniences.
4. Read Core Servlets , which will teach you the basics of servlets and JSP (the web layer of J2EE development). It will help if you already have a strong concept of the HTTP protocol from previous experience in PHP, ASP, Perl, etc.
5. Join a J2EE-focused mailing list (such as struts-user, j2eerocks, etc), and read the posts. Whoever said you don't learn via osmosis never subscribed to a mailing list -- even if only subconsciously, you will start to pick up terms and concepts such as design patterns or unit testing. Eventually you will find yourself answering the most-frequently-asked questions (usually with a link to the archives).
6. Learn how to use Struts and JSTL, using either online tutorials or a book (any will do). This will help you unlearn the bad habits of using scriptlets as they are taught in Core Servlets (see above). It's good to know what they are and how to use them, but stick with an MVC framework and JSTL for real development.
7. Now you need to fine-tune your Java knowledge. Read Sun Java Certification by Kathy Sierra and Bert Bates, which practically guarantees you'll score above 90% on the SCJP. At least you'll master all the nuances of the language that were left out of BJO and TIJ. This book should not be ignored.
8. Read Mastering Enterprise JavaBeans by Ed Roman et al. This is the final stage of your J2EE training, where you learn how to write and use EJBs. Then realize that for most applications, EJBs are overkill and go back to using DAO with JDBC or some other persistence framework. But you should still know this stuff.
9. Finally, start refining all of this knowledge by reading some patterns books like Agile Software Development: Patterns, Principles, and Practices, or Patterns of Enterprise Application Architecture. Fowler's Refactoring is pretty good too.

Of course, you should be actively engaging with these materials and coding as you go along, or none of this will stick. It took me about ten months, following this lesson plan, to consider myself a J2EE programmer -- and I started at the beginning, knowing nothing but PHP and Perl. I'm now an employed J2EE programmer (becoming a rarity in this country).

School Prep

[czion3]

This previous school year I took the first year of a two year computer science class (I am part of the first year where the AP exam will be in Java instead of C++ ). I will not be able to take the second year next year because of scheduling conflict but will be able to take it my senior year. Our class left off at advanced math problems being solved by recursion (the Towers of Hanoi problem sticks out in my head.) What would be a good book to review what we learned this year and be prepared for my second year of the class?"

$4.50 CHEAPER

[Anonymous Coward]

Amazon has it for $4.50 cheaper than bn!!!!

SO YOU ARE THE AMAZON WHORE!!!!

[Anonymous Coward]

So You Are The Amazon Whore!!!!

WHICH set of basics?

[alispguru]

Even if I only have a library of 5 books, I'd still rather have only one that covers the basics. That way, I don't have to dig through five different, sometimes conflicting, explanations of the same concepts.

Ah, but which basics? The term "object-oriented" means different things to different people. The differences you're seeing in these books are probably caused by this.

Go read this article by Jonathan Rees, and you'll see why Java OO != Smalltalk OO != CLOS OO (to name two models you've probably seen, and one you probably haven't).

O'Reilly's "Learning Java", 2nd ed.

[The Revolutionary]

I found the first edition of this book to be very helpful in becoming proficient in the Java language and standard libraries.

It covers all of the important concepts, really in as much detail as I believe one might want short of looking at the API documentation itself, including many particularities of each that aren't quite so intuitive: types, objects, classes, interfaces, io, threads, collections, reflection, beans, Swing, and more.

Looking at the O'Reilly website, I see that the second edition of the book also includes discussions of regular expressions and NIO, the new higher performance I/O system.

I won't be purchasing the second edition of the book, but if you are new to Java, I believe I can recommend it.

You get an overview of the entire language and the important standard libraries. It provides enough detail that it can often serve as a reference until you feel comfortable using the Java whitepapers and API specifications as your primary reference.

700 pages.

If you don't have a lot of experience with really taking advantage of object orientated concepts and design, and you find yourself using Java more than C/C++, I also recommend Oreilly's, "Java Design Patterns: A Tutorial". It puts much of the content of the original Design Patterns book into a Java context, and gives you numerous detailed and concrete examples of employing these patterns in Java and especially in standard Java scenarios. It provides suggestions for how to tell if you should use a particular pattern, as well as the advantages and disadvantages of each.

I'm certain that reading it will help you produce Java code that is more elegant and more maintainable. It will also help you be more conversant in object orientated design concepts.

And oh yes: avoid implementation inheritance unless you have a very good reason to use it; saving lines of code is not generally such a reason =)

Out of interest...

[Paul87]

Why does the Slashdot Java icon look like a bucket of steaming poo?

Ah. Never mind.

Java security documentation

[Anonymous Coward]

http://cgisecurity.com/development/java.shtml

I'd like to see this guy's code...

[Anonymous Coward]

The topics range from the common (objects, polymorphism) to the rare (RMI, sockets, exceptions).

If this guy considers exception handling to be a rare occurance in Java, he's got another thing coming when he tries to use just about any part of the Java API.

Good review

[honestpuck]

This is a good review. I liked the reviewers take on the two books and he certainly told me what he liked about the book being reviewed.

He could, perhaps, have told us a bit more what he didn't like.

Tony

I've been lucky

[peter303]

My brain absorbs technical manuals like a sponge. I can read a coding reference book and write significant working code in a few hours.
I wish I had the same power to learn human languages that way.

How nice

[Anonymous Coward]

Well, I'm glad that at least UML is covered in that book. Looking over it after buying all the rave reviews, I concluded that it was basically a waste of paper and never left it underneath my couch.

Re:why

[Anonymous Coward]

hehe i've been laughing at that for the last five minutes... and i'm at work, damnit!

Learning OO techniques in Java

[Brian Blessed]

Having recently completed a physics PhD, I decided to learn how to program more rigorously. As the reviewer suggested, I read Beginning Java Objects followed by Thinking in Java. Having browsed through a few other books before reading BJO, I really think that it is particularly useful at highlighting and explaining the important concepts of OO programming. After reading this book I found that many aspects of Java that previously seemed very confusing were crystal clear and I wondered why I hadn't picked it up sooner.

In Jackie Barker's book she often uses a Student Registration System as an example application. I enjoyed following her thought process in developing this application, and learnt a lot from it.

After reading this book as a basic introduction to Java, I read Thinking in Java and found that I was able to get more from it. It filled in many gaps in my knowledge, and extended many of the ideas presented by Barker.

For anyone wanting to learn Java or OO programming, I highly recommend BJO as a starting point.

Re:O'Reilly's Java Design Patterns Tutorial

[Anonymous Coward]

Can't find the book you referenced

Oreilly's, "Java Design Patterns: A Tutorial"

on the O'Reilly site - can you provide ISBN or a link?

thanks

Re:O'Reilly's Java Design Patterns Tutorial

[The Revolutionary]

Oops, Java Design Patterns is an Addison-Wesley book, not an O'Reilly book.

I read that one through O'Reilly's Safari service (which is great by the way), and hence the point of confusion =)

ISBN: 0-201-48539-7
publisher link: Java Design Patterns

I concur

[sbszine]

I took a Java class last semester and decided to use Learning Java instead of the course textbook, the abysmal An Intro to Object Oriented Programming with Java (by T. Wu).

I knew I had made the right decision when I looked up the continue statement. The O'Reilly book said 'terminates the current iteration of the innermost loop and evaluates the boolean expression that controls the loop', whereas the Wu textbook said only 'reserved keyword -- do not name a variable continue'(!)

Why do people think they know about Java

[Anonymous Coward]

I always amazing me the number of people who think they know something about Java.

Here is a list of the nonsense the typically spout:
1. Java is interpreted and therefore slow. (every heard of Hotspot of JIT). There are numerous (non MS) benchmarks proving that Java is fast.

2. Nobody uses Java.
Wrong again
If this is true who are those millions of people regestered at Java sites??
(just visit http://www.tiobe.com/tiobe_index/index.htm to see that Java ranked number 1)

3. Java is only used to write applets.
(I am a Java programmer and never write applets).
(ever heard of J2EE).

4. Java cannot call native code.
(ever heard of JNI)

5. Microsoft no longer supports Java therefore it is dead.
(This one is really funny, Java programmers don't care about MS. They don't even have to deploy their apps on Windows if they don't want to. Because Java is cross-platform we can simply switch to Linux without recompiling our apps) The only Java support Microsoft ever provided what their ANCHIENT Virtual Machine which only supported the version of Java my grandpa used)

-Java is that anchient version 1.1 I tried a few years back. (The latest version is 1.4.2 and 1.5 will enter beta shortly. You can't even begin to compare these to those old versions in terms of performance or functionality)

-.NET is way better than Java because
a) It is compiled while Java is interpreted
b) It is revolutionary
c) It comes from Microsoft
(a - Nonsense: .NET is JIT compiled, while Java has moved on from being Iterpreted (MANY years ago) to JIT compilation. It has now moved on even further and uses an advanced optimizing JITTER. Do a search for "Hotspot Whitepaper" to read more)
(b - Utter nonsense, anyone with a brain can see that .NET is based HEAVILY on Java and that Java is by far more mature )
(c - Who cares about MS)

Re:Why do people think they know about Java

[mantis78]

I don't have mod points to mod you up but
I have to say that you mentioned very good
points! :-)

Re:dont like java

[oroshana]

When you say "at runtime" do you mean as the program loads, or as the code needs to be executed? I'm just wondering.

Grammar Nazi

[brlewis]

At least I escaped the wrath of Grammar Nazi.

You know someone whose parents named him or her Grammar Nazi? If not, you should have said the Grammar Nazi if referring to someone in particular, otherwise any Grammar Nazi.

P.S. I might question the capitalization on Grammar Nazi, but I don't want to pick nits.

Re:dont like java

[AKAImBatman]

Depends on the JVM. Older JVMs would do the translation on load, while newer JVMs will actually interpret byte code until it shows itself to be a "hotspot" for optimization. Then the JVM optimizes the hell out of it. This way the JVM can spend more time optimizing the critical sections for better performance instead of wasting the user's CPU time by compiling and optimizing large chunks of code that will only be run once. That's why Java programs may seem to speed up as you use them.