After Learning Java Syntax, What Next?

Niris writes "I'm currently taking a course called Advanced Java Programming, which is using the text book Absolute Java, 4th edition, by Walter Savitch. As I work at night as a security guard in the middle of nowhere, I've had enough time to read through the entire course part of the book, finish all eleven chapter quizzes, and do all of the assignments within a month, so all that's left is a group assignment that won't be ready until late April. I'm trying to figure out what else to read that's Java related aside from the usual 'This is how to create a tree. This is recursion. This is how to implement an interface and make an anonymous object,' and wanted to see what Slashdotters have to suggest. So far I'm looking at reading Beginning Algorithms, by Simon Harris and James Ross."

Effective Java

[sproketboy]

Effective Java [sun.com] by Joshua Bloch. Will give you some deep insights into the workings of the language.

You've got one third of it

[AdmiralXyz]

In my experience, there are three things you have to do when learning a new language, after you get the syntax:

• Learn some common algorithms, and how to implement them in that language. Sounds like you've got yourself an algorithms textbook, which is great. Just make sure you're understanding why they work, not just going through the motions.
• Learn the standard library of the language. Obviously Java's is enormous, and there's no way a human being could possibly keep it all in their head, but you should check out the Java API [sun.com] and get a sense of, "what things are available to me in case I need them?" Java in particular makes it very likely that something you're trying to write already exists in some form, and there are a lot of programmers who waste valuable time reinventing the wheel every day because they don't know enough about the standard library (the flipside though, is that, just like algorithms, you need to make sure you know what you're using. Way too many programmers throw in a java.util.LinkedList without knowing what the hell it is)
• Experience! Write real code! This is the most important thing of all. The best experience comes from working in a group on a larger project, although of course that's not always possible. Try writing some larger programs on your own, making sure you keep your good design principles (use interfaces, abstraction, modularization, etc.) from start to finish. When you feel you're ready, there are plenty of open-source projects on Google Code in Java: download one and tinker with the source until you understand it. Hell, join the project if you're ready.

Good luck, and godspeed.

My top 4

[Ianopolous]

There are several very important books: 1. Effective Java - Joshua Bloch. This is by far the most important one. 2. Java, Concurrency in practice - Goetz 3. The art of multiprocessor programming - Herlihy and Shavit. This is much more theory oriented, but essential to become an excellent multithreaded programmer. 4. Java Puzzlers - Joshua Bloch and Neal Gafter. This is quite a fun book - lots of Java Conundrums Enjoy!

Re:How about the obvious...

[SnapShot]

If you can't decide on a project, yet. I'd recommend two books: Java After Hours (perfect for a security guard) and Wicked Cool Java. They're both the same basic format, each chapter exposes you to a new library. Wicked Cool Java covers more ground, Java After Hours is a little more detailed for each project.

Algorithms, Patterns, Refactoring

[TwinkieStix]

If you want to work in the real world, writing software, you're going to have to speak to other engineers about what you are doing at a level of abstraction higher than "for loop" or "switch statement". You'll want to talk about algorithms and even more commonly, patterns. You may already be familiar with "tree" and "linked list" so you're off to a good start. But, in the future, you'll find yourself saying: "This is a visitor", "this is a controller", "this is a command pattern", etc. The current "bible" of these patterns is known as the Gang of Four book:
http://www.amazon.com/Design-Patterns/dp/0201633612 [amazon.com]

That one is a hard read. I understand that a more digestible book is this one:
http://www.amazon.com/Holub/dp/159059388X/ [amazon.com]

Two other routes you will want to go down is that of algorithms, like you already mentioned, and refactoring. Algorithms are the most common next step in College, so it might be wise to do that before patterns and refactoring, but I don't think either is a prerequisite for the other. But, knowing what "Big O notation" is, and understanding why a divide and conquer sort is so fast is helpful in your career.

Finally, refactoring seems to be the hidden art of writing good code. So few programmers really understand how to refactor bad into good. This advanced topic will be what sets you apart from the other engineers you compete with for a job. This one is a good "bible"
http://www.amazon.com/refactoring/dp/0201485672 [amazon.com]

Re:Do we really want him writing code?

[Apathist]

When the number of items is small; when insertions and deletions are common and/or time-critical; when ordering is important...

Any of the above could alone be good enough reasons to use a linked list vs. a hash table, and obviously more than one criterion would make a stronger argument. But this is a very one dimensional discussion; in any of those cases, perhaps an array or an ordered tree would prove more appropriate... each case must be matched to a particular data structure on its own merits.