Work have told me to go off and learn Java SE 6, so as a first point of call I want to get a book / some books which will go from Novice to reasonably well informed.
What can you recommend to me?
Work have told me to go off and learn Java SE 6, so as a first point of call I want to get a book / some books which will go from Novice to reasonably well informed.
What can you recommend to me?
thought this was another coffee thread...
start here
more specifically here
For a developer crossing over to Java, I found Java in a Nutshell great. That was in 1999 though.
Hard to recommend other books though, I don't read em
In general though, computer books need to be looked through and bits read, so that you can gauge the tone. Some are loads of waffle and jokes that baby you through stuff, some are succinct and to the point. Which you prefer depends on you
I've just worked through Head First Java, which I tought was really good. Much more readable than O'Reilly's Learning Java
Some good suggestions over on Stack Overflow:
http://stackoverflow.com/search?q=java+book
I have been told to focus on the Core libraries, does the head first book do this?
I have a programming background so I don't need one that explains how control structures or iterators work.
I didn't like the style of the Head First series, kinda "java for dummies"/comic/patronising style, but thats personal preference.
I used sun's Core Java series and would recommend them if they're still doing them. Excellent overview of the core libraries and examples that are easy to learn from and make good references for experienced developers.
The Sun Java Tutorial always used to be a reasonable starting point... What kind of programming background have you got?
Yeah the head first series are definately on the less serious side, and found that the main reason I'd pick it up for a couple of hours and work through it, rather than finding other things to fix.
Also found the Sun online tutorials useful when I needed to look busy...
+1 for the Sun Java Tutorial, it's somewhere on their website.
Grab a copy of JCreator too (it's on the torrents, if you don't want to pay for the Pro), it's a good (IMHO) Win32 Java IDE.
forget all that here's a free way to start
- firstly download Eclipse = a development environment with intelligent prompts...
http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/heliossr1
then there are various tutorials with Eclipse
http://eclipsetutorial.sourceforge.net/totalbeginner.html
or (particularly if you've programmed before) I looked up this old version of Java
http://ibiblio.org/java/javatutorial.html#xtocid45975
The challenge is to get some of the examples working on the latest version of Java. Which is good becuase you then have to problem solve and you only truly learn from problem solving.
DaRC_L ---At what point does any of that that give an overview/introduction to the core libraries/packages as the OP asked??
prog exp. comes from a M$ background, VB, ASP (Javascript and CSS as well) and VB.net with some exposure to C#.
I wouldn't bother with JCreator, Eclipse is free and pretty much the standard Java IDE (at least here in Spain...)
OP, the reason I asked about your experience programming is that if you're coming from C++ you'll know all about OOP, if you're coming from VB or similar you won't. And to be any good at Java you really do need to get the basics down: how a classloader works, inheritance, what the virtual machine does, etc.
Edit: cross posted with the OP!
I can recommend Robert C Martin's "Clean Code" as a good book on how to avoid writing 'orrible Java... Actually, it applies to all languages really.
I learnt by using a few online tutorials and then playing around really. You'll come up against all the various libraries at some point as and when you want to do something (JSP, junit, swing etc.)
I would make the suggestion that rather than learning the language using an IDE (i.e. eclipse), you are best off learning the core language using a syntax-highlighting text editor (erm...vim happens to be my weapon of choice, but there are many options). IDEs generate a lot of boilerplate code for you when generating classes etc., but in my experience newcomers to the language gain a better understanding of how it works by starting off generating all that themselves. When you understand how all those bits hang together, then let an IDE do the boring work for you.
Grunty, with that experience I would definitely recommend Nutshell. It soundly goes over (or did at least) the principles of OO before going into the language. It's aimed at people from a C background.
If you are from a MS background, then an IDE might be a good way to learn. You will eventually arrive at the same place as if you'd learned command line style but probably somewhat more easily. I haven't compiled anything from the command line once in my professional career.
If you were from a unix background though it'd be worth it.
IDEs generate a lot of boilerplate code for you when generating classes etc
Eclipse doesn't, if you are doing plain Java code. Netbeans does if you are developing Swing say, but that's a whole nother kettle of fish.
I would not recommend "Java in a Nutshell" - I thought his programming style innappropriate for an OO language - whereas "C# in a Nutshell" is prety good.
I learnt Java in four weeks which included writing an order matching, socket based exchange for testing purposes.
I tried Java in a nutshell but ended up with Bruce Eckels free book:
http://mindview.net/Books/TIJ4
but preferred reading James Gosling's "The Java Programming Language":
followed by "Effective Java":
http://www.amazon.co.uk/Effective-Java-Second-Joshua-Bloch/dp/0321356683/ref=pd_bxgy_b_text_b
and the "Java Cookbook" to get me going:
http://www.amazon.co.uk/Effective-Java-Second-Joshua-Bloch/dp/0321356683/ref=pd_bxgy_b_text_b
1st two are probably still appropriate, third might be dated but equivalents can probably be found free on the net anyway.
Avoid anything by Herb Schildt.
Eclipse is nice - using a TDD style is good as well and is the bit I liked most about Java development as it was my first exposure to that paradigm.
I can't really comment on a book as I learnt Java as part of my undergrad degree so didn't bother buying one. I'll agree with TurnerGuy that TDD using JUnit testing is a really nice way to write Java. Eclipse is what the uni made us use but i never got on with it myself.
I'll agree with TurnerGuy that TDD using JUnit testing is a really nice way to write Java
Argh!
TDD is only good if it's appropriate for the project!
Another vim user here
TDD is only good if it's appropriate for the project!
explain?
main problem is with anything async as I see it...
Argh!TDD is only good if it's appropriate for the project!
So is any methodology, just saying that in general it makes nice Java!
which projects aren't appropriate for considering test cases and failure scenarios up front, then?
......opens a cold beer and sits back in a comfy chair.
which projects aren't appropriate for considering test cases and failure scenarios up front, then?
Ones where the entire project isn't completely and fully specified or even understood up front. Which is most, in my experience.
TDD is only good if it's appropriate for the project!
Agreed - Unit Testing is always a good thing, especially when properly automated - but full TDD isn't always useful.
Plus the term 'unit testing' varies depending on what you consider a unit.
Plus the term 'unit testing' varies depending on what you consider a unit.
In an OO language I generally consider the smallest unit to be a single class.
Though I'll often (also) write "unitty-integrationy-tests" which involve a subsystem of a couple of important classes.
But your classes might be weighty slabs of code, or simple beans.
If your classes are "weighty slabs of code" then you're doing it wrong
http://en.wikipedia.org/wiki/Single_responsibility_principle
Quite possibly.
At my last project, the unit test policy resulted in people having to write unit tests to see if their getters and setters had worked.
Projects fail for a variety of reasons. Often not because classes weren't fully unit tested.
The unit testing problem. The modern style is for small classes and frequent refactoring within packages. So I reckon that with some exceptions packages are the level to test. Otherwise the test are constantly bring refactored to. That defeats the objective of them in TDD. But it's all opinion.
TDD != Unit Testing;
This topic has been closed to new replies.