8/7/2014: In conclusion? I am not confident with anything I am writing here. I hope I can better analyze everything, and consolidate my experience with this traumatic book when/if - no, when - I become more proficient with the Java language. But I think what I am about to say does hold some truth, since it is catered for the likes of me. Alright, what is positive? It's clear in every piece of information that it gives. It's to the point, and I love that. I like the fact that there is a focus on mathematical programming. Makes it tougher, but you would come out ahead. On that note of clarity, the glossary was fantastic. It helped immensely; and it was a perfect idea to put a definition list at the end of each chapter. Now the bad, was really bad. As I said earlier, the amount of inference you have to do, the amount of presumed internet excavation you have to dig out is not acceptable in any capacity. If certain challenges are presented, then actually illustrate them in code. Don't tell me to look it up, or surprise me with a completely new challenge that I have never heard of. That just breeds bad coding habits. Something that should be emphasized as keeping to a minimum.
Did I learn? Yes, I did learn to swim-- at least I have a better understanding. I would appreciate it if I was thrown into a body of water with some flotation devices. Better yet, if I wasn't thrown into an ocean, but a kitty pool.
I don't recommend this; there are better books out there. Free doesn't mean good. This is not good.
I am a bit less than half-way through with this textbook. So I'd really like to say a few things as I get into the second half, and try to finish it in the next two weeks. And adding a second review might help prospective students.
This is my second Java reading; but my first textbook. I delved into one prior to just a simple reading on the language, and found it daunting. So I went with a "Dummy" book to ease me into things. At this point, I don't think I made a great choice; but I did make a challenging one.
First, the book recommends compiling from the command line/prompt for all exercises. A lot of CS go-ers definitely advocate for this practice. I tend to agree, as it can be quite rewarding. But it's definitely not a productive-conscious environment. The majority of programmers are using their favorite-flavored IDEs for optimal coding. Aside from being a slower method, it also has its learning curve. Unfortunately, this textbook does not even attempt to show the reader basic commands to compile, or setup the correct path variables. It tells us simply to "look it up". That's not exactly what a novice wants to hear.
Luckily, I do know the basics of compiling from cmd so I tried it out for a few chapters, but I subsequently went back to Eclipse.
My second gripe with the text so far is the exercises. Usually inferring is a given when learning anything; but I usually find inference is best applied to problems when examples are abundant. Here, they are minimized but the inference level is high. E.g., I had to figure out how to manipulate a method with multiple parameters through main; or currently in ch 6., how to execute a program without invoking main (regardless of the fact that method main has been implemented in every exercise thus far, and no example exists where it is not invoked). So, there is definitely a lot of Googling done by me - probably every other exercise.
The challenge is great; and I will probably come out stronger because of it. However, I feel like I am learning from a last-minute substitute teacher with general notes; instead of a dedicated tenure professor.
I won't say what exactly I recommend just yet, but I will say to start with a textbook that isn't less than 300 pages long (think: How To Program, etc.). Or perhaps the "Trails Covering the Basics" from Oracle online. If you'd like to read this one, I suggest this be your 'third introductory' textbook.