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.
Writing lots of unit tests, or thinking how your code can be tested before writing it is not TDD.
We know. No one said otherwise.
But unit testing is the basis of TDD, hence the bit where I said [i]"Unit Testing is always a good thing, especially when properly automated - but full TDD isn't always useful."[/i]
Have you lot ever worked on a project that was fully and adequately specced before development started?
I wasn't referring to any of your posts GrahamS
Have you lot ever worked on a project that was fully and adequately specced before development started?
Nope, but I've worked on plenty of safety-critical systems (medical, military, financial) where they don't like it much when stuff goes wrong.
Right, so the way you develop safety critical stuff isn't the way you develop non-critical web based apps, say 🙂
the project in question issued a dictat saying we had to have 90% unit test coverage
Not unusual - I believe there's quite a few of the OS projects now demand 80-90% coverage.
A framework that requires lots of getters and setters sounds a bit broken. But yes, that could be a reason
Fairly common in Java web frameworks, JSF and IceFaces for example require it.
Not unusual - I believe there's quite a few of the OS projects now demand 80-90% coverage.
Which as diktat is stupid - I'd like 100% coverage on the important stuff, and closer to 0% on the boilerplate.
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.
Personally I'd probably have used something like [url= http://www.unitils.org/summary.html ]unitils[/url] to automatically test the getters/setters (or just written my own using BeanUtils).
Huge code coverage increase, minimal impact on time, budget or morale 😀
Right, so the way you develop safety critical stuff isn't the way you develop non-critical web based apps, say
Yeah I'm mainly talking about proper software [u]engineering[/u] of important systems, not just hacking about on the web 😀
Which as diktat is stupid - I'd like 100% coverage on the important stuff, and closer to 0% on the boilerplate.
The guiding principle of unit testing [i]should[/i] be "test everything which can possibly break" and as demonstrated the "boilerplate" can break.
But yeah, I agree that testing the bits that are more likely to break is a good approach on systems that are non-critical and don't have the budget for proper full testing.
The guiding principle of unit testing should be "test everything which can possibly break" and as demonstrated the "boilerplate" can break.But yeah, I agree that testing the bits that are more likely to break is a good approach on systems that are non-critical and don't have the budget for proper full testing.
You're assuming end-to-end responsability for the entire system, though - if the client demands I use, say, Hibernate, I'm not about to test it. If it goes wrong it's his problem, not mine!
And technically speaking it's not "hacking about on the web", it's "well-paid minimal-risk programming". 🙂
if the client demands I use, say, Hibernate, I'm not about to test it. If it goes wrong it's his problem, not mine!
All the more reason to test YOUR boiler plate code.
Yeah I'm mainly talking about proper software engineering of important systems, not just hacking about on the web
I meant enterprise systems with a web front end, not silly websites.
If time is at a premium I'd rely on system testing. My principles involve writing code that is so clear and simple that every block of code is obvious as to whether or not it works just by looking at it. Integration is where you are most likely to get bugs, which is where system testing comes in.
If I'd commissioned a system and they were spending my money testing to see if the line a = b; does indeed result in a being equal to b, I'd be bloody annoyed.
That's what we ended up doing with the 90% coverage thing.
But we do seem to agree with what I said originally, which is that you would set your working practices according to the customer's situation.
You're assuming end-to-end responsability for the entire system, though - if the client demands I use, say, Hibernate, I'm not about to test it. If it goes wrong it's his problem, not mine!
Hibernate would be covered by normal Verification and Validation (V&V) of Off-The-Shelf (OTS) software, as per the Capability Maturity Model or similar.
So no you wouldn't write unit tests to test Hibernate. That would be daft. But you would (ideally) still test your classes that interface with Hibernate (though if they were really just data POJOs with no logic then I'd probably test them automatically as mentioned).
I meant enterprise systems with a web front end, not silly websites.
I know, I'm just tweaking your leash for suggesting I have no valuable experience to add 🙂
But we do seem to agree with what I said originally, which is that you would set your working practices according to the customer's situation.
We are. Compromise is part of the job.
(Incidentally, I've done 100% code coverage projects! Now that sucks!)
Java Gurus?
Is this a bit like the Kama Sutra? 😯
(though if they were really just data POJOs with no logic then I'd probably test them automatically as mentioned).
Why bother at all? So you could get a 100% coverage figure?
I know, I'm just tweaking your leash for suggesting I have no valuable experience to add
That in turn was in jest as I am sure you understand.
I once wrote a booking system for a hotel on my own under extremely difficult circumstances. Finished the last thing at 3am one morning, emailed the lady to say the code was done and it was deployed, thinking we'd start some testing. 11am the following day, got in to the office and there were 4 call centre girls taking bookings on it!
Worked absolutely fine, couple of minor bugs. All due to my transparent code 🙂
Incidentally, I've done 100% code coverage projects! Now that sucks!)
Still no guarantee of bug free code - shhhhh - but dont tell the PM 🙂
Why bother at all? So you could get a 100% coverage figure?
Because, as demonstrated, even simple, no-logic, no-validation getter/setters can have bugs (and can be quite prone to them, as people will copy-paste them and they will be barely glanced at during all but the most diligent code review).
If you think testing getter/setters makes no sense in Java then try my earlier example but this time in C#:
[code]class DepositAccount
{
public int Balance { get; set; }
public int AccountID { get; set; }
}[/code]
Now [I]that[/I] has nothing worth testing.
Because, as demonstrated, even simple, no-logic, no-validation getter/setters can have bugs
Only if you really try to put them in there!
What about peer reviews? Buddy programming? Component level testing? All alternatives that have less overhead imo.
Only if you really try to put them in there!
Typos and copy-paste errors happen. In my experience, complex code can sometimes have less bugs in it than the simple stuff - purely because the complex stuff catches peoples eye, it makes them think and so it will be carefully examined during code reviews, walkthroughs and subsequent coding.
All alternatives that have less overhead imo.
I wouldn't cite any of them as alternatives. They all complement unit testing.
And what "overhead"? I already pointed out you could always automate the simple no-logic testing. Even if you don't and you choose to write it by hand, what are we really talking about: a couple of extra lines in your unit tests for that class. Probably take less than a minute to write.
If you unit test and system test, you've done a 100% thorough job. If you only system test, you've done a 99% thorough job in maybe half the time.
Like I say, it depends on the project and the customer. And what you consider a unit.
This discussion needs an exit clause.
A system level test will barely touch the sides in terms of coverage.
And in terms of overhead, I'd much rather a silly bug was quickly found by the developer that wrote it without anyone else seeing it, rather than it making it up to component/system level where some tester finds it, raises a bug report, which a PM has to assign and monitor, and some other developer has to investigate, fix then provide a test showing it was fixed and fill out bug tracking information.
Anyway Exit clause:
[code]if (time.IsBedtime())
exit(Status.SLEEPY)[/code]
- Its easier to review tests than code.What about peer reviews?
- One for the price of two !Buddy programming?
- ????Component level testing?
static {
statuts = "GoodNightJohnBoy";
}
Ones where the entire project isn't completely and fully specified or even understood up front. Which is most, in my experience
agreed - but that is one of the drivers for XP/Agile and TDD, with short iteration releases to the client to mitigate this problem. The 'client' may only be internal, such as a local domain expert that wants to see how the release is progressing and address any issues that may have come to light from an inconsistency/incompleteness of the external clients specification - delivering early allows time for this to be addressed before the final release to the client.
With TDD you write tests to prove the functionality that you are delivering for this release - the code does not have to be perfect/interfaces do not have to be complete - the priority is only to satisfy the tests.
Obviously the developer is probably under time pressure, so instead of making the code perfect she should make the tests perfect.
Then you tackle the functionality required for the next release, so you write tests to prove that functionality, refactoring as you go along to ensure the code remains/reaches a decent state. The refactoring is protected by the tests being in place, without the tests the refactoring is risky.
If the required functionality changes along the release cycle you may need to refactor the tests, or you may need to refactor them if functionality moves between classes.
The point of pair programming is to have two people thinking up the tests, which, like debugging, is often more efficient than leaving it to one person. Writing the actual code is the trivial part.
Having a suite of automatically run unit tests and, where possible, automatically run system tests, leads to much more stable and mature systems. If a bug is found the first thing to do is to write the missing test that would have exposed it, then to fix it.
Code reviews have much less relevance nowadays as it is more difficult to grock what the code is doing from just reading it. Peer reviews were one developer explains the code and functionality to another are much more useful.
Making excuses such as TDD is not appropriate to this project or there isn't time to write the tests is just making shortcuts and increasing the risk of developing a project that is going to fail.
TDD also often forces a better design as components have to be written in a manner where they can be tested in isolation and therefore have clearly defined interfaces and roles/responsibilities.
The tests are to test logic, testing getters and settings is pedantic. If possible classes should be made immutable anyway. Testing that all properties are set after construction can be surprisingly useful, however 🙁
It is also often useful to write tests (integration?) tests to prove that a library/framework behaves as you are expecting in your application, not to just assume that it works that way because the documentation says so. It also protects you from breakages when you update that framework.
Obviously the developer is probably under time pressure, so instead of making the code perfect [b]she [/b]should make the tests perfect.
Sexist!
😉
Code reviews have much less relevance nowadays as it is more difficult to grock what the code is doing from just reading it
I would disagree in my area of enterprise application development. Mostly you are just tying APIs together, and the code itself is very noddy.
As for buddy programming - two developers often work more than twice as fast as one, ime. No time for daydreaming, surfing STW or general slacking.
Turner guy seems to be talking about large systems undergoing continuous development and maintenance within an organisation. Like I keep saying, these approaches are all tools you can deploy [b]if appropriate[/b].
I have also used TDD style for smaller projects and love the feeeling of solidity you get from it - the time taken writing the tests is easily compensated for by the lack of the traditional debugging.
Before using that style I would like to walk through new code in the debugger, as recommended in "writing solid code", but find the need less now. And when using 'technologies' like xslt using TDD style tests to prove the logic you want is invaluable, as it often doesn't work as you think it should from looking at the code.
With mickey mouse languages like Java and C# I feel TDD is essential, but have used it with C++ to good effect.
Async stuff is a problem still, but it is better than nothing.
The tests are to test logic, testing getters and settings is pedantic.
Yes, yes it is. Aren't tests supposed to be pedantic??
I don't test to prove that it is more or less basically right, give or take.
Likewise I use a compiler set to -pedantic, I am pedantic about fixing warnings and I use pedantic tools like lint, StyleCop, BullsEye, etc.
Code reviews have much less relevance nowadays as it is more difficult to grock what the code is doing from just reading it. Peer reviews were one developer explains the code and functionality to another are much more useful.
The trouble with peer-reviews is that it is like someone reading you an essay they wrote, rather than reading it yourself. It is easier to understand their intent, but much harder to spot basic errors.
If the code is hard to grock then it is poorly written and documented. A future maintenance programmer may not have the luxury of the original author on hand to explain it - so it should be understandable without him/her.
Exactly.
I like to write code that's so obvious it doesn't need documentation apart from on a high level.
grock
?
Grok, surely. And if you fail at that level of basic geekdom, I don't want you anywhere near my code!
And don't talk to me about coding standards that make you javadoc every single method, member, ... 🙄
code that's so obvious it doesn't need documentation apart from on a high level
So its undocumented as well as untested....
.....oh the horror, the HORROR ! 🙂
So its undocumented as well as untested....
But working perfectly, delivered before the deadline and under budget to a very happy client.. How is such sorcery possible?!
Grok, surely
that was a trap to catch the true geeks who would correct the spelling error...
The trouble with peer-reviews is that it is like someone reading you an essay they wrote, rather than reading it yourself. It is easier to understand their intent, but much harder to spot basic errors.
Whereas just reading code used to be useful in the days of simpler coding styles/languages, nowadays it can be less easy to see the full intent of the code by just looking at it, with active objects, event handling, etc.
Therefore having the author explaining the code and intent of the system to the reviewer(s), possibly at her terminal tends to offer high value as well as low overhead and is worth doing. Old style code-reading is rarely worthwhile.
I'm not a geek, that's why I'm good at my job 🙂