Covariant Return Types in Java 5

Covariant return types are one of the newly added features in Java 5. Using covariant return types, an overridden method in a derived class can return a type derived from the type returned by the base-class method.

For example in the Java versions prior to Java 5, the following would have thrown a compile time error.

class Vehicle
{
Vehicle myFunc(){return this;}
}

class Car extends Vehicle
{
// myFunc() returns Car, which is a subclass of Vehicle
Car myFunc(){return this;}
public void printMe(){ System.out.println("I am a Car");}
}

public class Covariant {

public static void main(String args[]) 
{
Car car = new Car();
car.myFunc().printMe();
}
}

CompileTime Error: The return type is incompatible with Vehicle.myFunc()

Prior to Java 1.5, to remove this error you had to make 2 changes.

1. Change the return type of derived class myFunc() to Vehicle and
2. Downcast Object being returned by car.myFunc() to Car

Java 5 lets you get away with that and makes the above code work just fine.

XP2010, Norway

All agile enthusiasts who missed out on, XP 2009, Tenth International Conference on Agile Processes and eXtreme Programming in Software Engineering, held in May 2009
at Sardinia, Italy could compensate for their loss by registering for XP2010, 11th National Conference on Agile Software Development to be hosted by the SINTEF research foundation in Trondheim, Norway.

Registration of the meet would begin in January 2010.

The conference, as per the official website, would focus specifically on theory, practical applications and implications of agile methods.

Deadlines
Dec 6th 2009     Research papers, experience reports
Dec 13th 2009     Lightning talks
Jan 7th 2010     Workshops, tutorials, posters and PhD symposium

You can find more information here XP2010

So start putting things in your boss's ears because it might take some time and some effort to make her approve the training budget.

Good luck.

Agile and your ROI

97 Things Every Software Architect Should Know

Here is a pretty good link for all the aspiring software architects

97 things every software architect should know - the book

Germany Scrum Gathering - 2009

Though I would not be able to make it to this event, I thought of letting all of you know about it.

Date:
Monday, October 19, 2009 - Wednesday, October 21, 2009

Venue:
Hilton Munich City
Rosenheimer Strasse 15
Munich, Germany 81667

Speakers:
Ken Schwaber - Scrum Co-Founder
Jeff Sutherland - Scrum Co-Founder
Mike Cohn - Mountain Goat Software

plus many more industry speakers, authors, trainers, innovators
and special sessions too!

Early payment:
Scrum Alliance Members - 1,200 euros
Non-member - 1,400 euros
CST/CSC 900 - euros
Early discount rates available until August 1, 2009.

Regular rates:
Members - 1,600 euros
Non-members - 1,800 euros.

Registration & information:
http://www.scrumgathering.org

PMP Tips: Standard vs Regulation

A Standard is a “document established by consensus and approved by a recognized body that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at achievement of the optimum degree of order in a given context.”

A Regulation is a government imposed requirement, which specifies product, process or service characteristics, including the applicable administrative provision, with which compliance is mandatory.

It's often seen that standards become so overly used, that with a widespread use, they take the form of a regulation.

Java Tips - Always Override toString()

I am sure all of us at some point in time of our software development career, would have done an SOP on an object, expecting to see an interpretable string value but were displayed a string, which could not add much to our understanding.

Though java.lang.Object provides a default implementation of toString() method, I dont think its really informative. The returned string consists of the class name followed by an @ sign and an unsigned hexadecimal representation of the hash code, for example, Employee@235b92.

Actually The contract for the toString() method says that the returning string sould be concise, easily readable and also all the subclasses should override it. Though it can be argued that Employee@235b92 is concise and small enough to read, but it certainly is not very informative.

Joshua Bloch suggests to override toString() method so that a suitable string interpretation of your object can be returned. Providing a good string implementation makes your class much more pleasant to use. Overriding toString() appropriately not only is beneficial to instances of your class, but it is also useful for the objects containing instances of your class. For example if you want to print the contents of a hashmap containing instances of your class, I am sure anyday you would prefer to see a Employee@BillGates_CTO over Employee@235b92.

Ideally, the toString() method should contain all the interesting information about the object. But if the object is really large it might not be possible to include all the information in returning string. In that case you can make it return something which provides a small summary of the object.

I know that you are not really familiar with this approach and might not find it a value adding practice but I would still recommend that you start using it and I am sure that soon you would start appreciating it's benefits.