Currently I'm reading couple of technical and agile books (see the nice gadget on the right panel) and one of the books is "Effective Java - Second Edition" by Josh Bloch.
Josh's item number 5 - "avoid creating unnecessary objects" tells me that I should not create (unnecessary) instances of classes like
He suggests using "heavy" objects only once, during the static initialization of the class:
I can agree with this point but on the other hand consider a following snippet:
This code does not perform initialization using Calendar but uses this class to perform some on-the-fly computations - this is the place where this example differs from the previous code snippets (I use "heavy" object after the class initialization and cannot do it in a different way). My code snippet is potentially dangerous: FindBugs tells me:
This way my code should be refactored to this shape:
But hey! Josh Bloch tells me that creating
Anyway I'm a bit confused - how should I use
What do you think?
Josh's item number 5 - "avoid creating unnecessary objects" tells me that I should not create (unnecessary) instances of classes like
java.util.Date and java.util.Calendar:
// DON'T DO THIS
public void someMethod() {
// unnecessary allocation of expensive object
Calendar cal = Calendar.getInstance();
...
}
He suggests using "heavy" objects only once, during the static initialization of the class:
public class Person {
...
static {
Calendar cal = Calendar.getInstance();
// do some initialization using Calendar instance
...
}
...
}
I can agree with this point but on the other hand consider a following snippet:
// DON'T DO THIS
public class Confusion {
private static final Calendar CALENDAR = Calendar.getInstance();
public void doSomething(Date date) {
CALENDAR.setTime(date);
...
}
}
This code does not perform initialization using Calendar but uses this class to perform some on-the-fly computations - this is the place where this example differs from the previous code snippets (I use "heavy" object after the class initialization and cannot do it in a different way). My code snippet is potentially dangerous: FindBugs tells me:
[STCAL] Call to static Calendar [STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE]
Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use. The detector has found a call to an instance of Calendar that has been obtained via a static field. This looks suspicous.
For more information on this see Sun Bug #6231579 and Sun Bug #6178997.
This way my code should be refactored to this shape:
public class Confusion {
public void doSomething(Date date) {
Calendar cal = Calendar.getInstance()
cal.setTime(date);
...
}
}
But hey! Josh Bloch tells me that creating
java.util.Calendar is expensive and he's the Guru - he must be right. Maybe I missed the point of "creating unnecessary objects" and in my example if I want to operate on dates using java.util.Calendar object this is really necessary?Anyway I'm a bit confused - how should I use
java.lang.Calendar objects? Using them as a final static constants is dangerous but on the other hand creating them every time I need it can deteriorate the performance or memory footprint. What do you think?
I was quite disappointed with this book especially when I read that agile development means lack of discipline (how about unit testing, pair programming, continuous integration, etc.) This book tries to give managers tool for deciding which methodology (waterfall/spiral/RUP or agile) is better to which kind of projects - the variables are criticality of the project (how many lives depend on this software), number of people developing this software and probably time (probably because I don't remember exactly). Anyway - I'm giving this book 3/5.
Excellent, brilliant, great book! This book is the best book written by Ken Schwaber about Scrum. It gives theoretical fundamentals for Scrum and answers the question "Why Scrum works better that waterfall for software projects?". If you use Scrum this book is absolute MUST for you. my score: 5/5.
I will tell you one thing: the 
