Forum menu
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...
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 - [u]Unit Testing[/u] 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 [b]not[/b] 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;
I know TDD != unit testing. But TDD means lots of unit tests no?
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.
Boring to write, but it doesn't take long and can still be useful, e.g.
[code]class DepositAccount {
private int balance;
private int accountId;
public String getBalance() {
return this.balance;
}
public void setBalance(int balance) {
this.accountId = balance;
}
}[/code]
Though if you're writing lots of classes with tons of getters/setters then "you're doing it wrong" (again).
The unit testing problem. The modern style is for small classes and frequent refactoring within packages.
All the more reason to have unit tests. How can you check your refactoring hasn't broken something without them?
That said, the unit tests should be checking the public interfaces of these classes, not the implementation (or you're doing it wrong).
means lots of unit tests
Yes it will mean there will be a LOT of tests, but thats no bad thing is it ?
Though if you're writing lots of classes with tons of getters/setters then "you're doing it wrong" (again).
Or using some framework that requires it.
Does the phrase 'teaching your grandmother to suck eggs' mean anything to you? 🙂
My point is, unit tests have their place, but dogma usually doesn't.
Yes it will mean there will be a LOT of tests, but thats no bad thing is it ?
Depends if you've got the time and budget for it...
Depends if you've got the time and budget for it...
So lots of tests aren't bad, but they're the first things to get cut when the pressure's on ?
You have to cut your cloth to suit.
Some projects are time pressured. That's how it is. Actual code is more important than unit tests for sure.
.... depends on the quality of the code 😉Actual code is more important than unit tests
I only chipped in to point out the difference between Test Driven Development and writing Unit Tests.
Writing lots of unit tests, or thinking how your code can be tested before writing it is not TDD.
Yes it will mean there will be a LOT of tests, but thats no bad thing is it ?
It is when the only thing they're testing is delegated calls to a hibernate style data framework, which is what happened on one project I was running. The client insisted on all public methods having tests, so we ended up spending loads of his money writing pointless unit tests. Soul-destroying for my team, and expensive for him. Idiot.
The framework also meant endless get/set, too.
I fully agree that they're great in a lot of cases, though.
Or using some framework that requires it.
A framework that requires lots of getters and setters sounds a bit broken. But yes, that could be a reason.
But (as I'm sure you know) the whole point of getters/setters is that they can contain functionality and hide implementation details - so there [i]can[/i] be errors in there which [i]can[/i] be found by unit tests.
Does the phrase 'teaching your grandmother to suck eggs' mean anything to you?
If you mean you've stopped trying to learn from the experiences of your professional peers then fair enough 🙂
My point is, unit tests have their place, but dogma usually doesn't.
No dogma here, I said unit testing was always "a good thing". I believe that to be true. I don't always do it tho - depends what the client wants and what the budget allows (as you rightly say).
If you mean you've stopped trying to learn from the experiences of your professional peers then fair enough
If you came out with experiences that weren't already obvious to someone of my experience then I'd be happy to learn 😉
The lead developer on the project in question issued a dictat saying we had to have 90% unit test coverage. The only way to achieve that was to unit test methods that just set a member. Valuable use of client time and money I think not.