I thought you meant the one with code in it, but you meant the one that I hadn’t seen which had tripedp the spam filter – so the “The class extends the Exception class” comment was held for moderation.

Just approved it and deleted the dupe!

Normal service resumes!

There’s currently 85 comments on this post and it’s working just fine, 8 post max? Non! =P

The use of this identifier is explained within this howto for Implementing Serializable.

Only implement Serializable when you have to!

Eclipse gives you a right-click option to resolve the compiler warning/issue, it basically auto-generates the code and unique number.

I didn’t put any exception code in because I was planning to get the date from a JCalendar “date picker”, so it should be pretty impossible to provide bad values and cause the conversion to fail.

Good point & well made tho. Also, what’s with the serialVersionUID?

default:
	friendly = "BadDayValue";
	break;

…consider using your apps own exceptions…

default:
	throw new InvalidDayValueWithinDate();
	break;

or,

default:
	throw new InvalidDayValueWithinDate("Could not determine day for calendar " + theDate.toString());
	break;

Because an invalid date would be an error in most cases. Depends on the app though.

Note that InvalidDayValueWithinDate is defined by the app writer like…

package org.r3dux.appname.exceptions;
 
public class InvalidDayValueWithinDate extends Exception {
	private static final long serialVersionUID = -911413132467019924L;
 
	public InvalidDayValueWithinDate(String s) {
		super(s);
	}
}

// surely this must be a thread record now

// Going for the thread post record

I thought that because I’m not using the new keyword at any point, any instance variables are placed on the stack, and get thrown away as soon as the method completes – no garbage collection necessary.

I believe you’re right in that String concatenation (+= style) uses copy-by-value instead of copy-by-reference (which I assume StringBuffer or StringBuilder is capable of), but as above, no heap usage so method’s stack container gets instantly deallocated on completion of the method and we get the memory back, like, BAAAAM! =D

That was my take on the memory management side of things from Head First Java, but it wouldn’t surprise me in the least if I’d got it a bit wrong.

This will also save you a lot of problems down the road…
Strings are IMMUTABLE. Once set they cannot be changed.
Say for example I have a 1k string and I want to add 1 character to it, what happens is that the original 1k string gets copied to a completely new string with the extra character. So now the memory contains just over 2k of strings until the garbage collector cleans up the unused and de-referenced strings.

Your code is creating new strings and moving object references from the old string to the new string all over the place in your example.

So what’s the solution? Use StringBuffer, or its newer cousin StringBuilder. They are virtually the same in how they’re used. The serialize method example shows how to do this.

Sorry to rip on your code so much; I made exactly the same mistakes too, I just want to help you avoid the pitfalls more quickly than I resolved myself.