Ho to not use casting on this generics?

[Johan Zahri]

Dear all,
I have the following code:

public abstract class Job<XResult extends Result> extends Thread {

	private int numberOfRetries;
	private int maxNumberOfRetries;
	private Input input;
	private XResult result;

	public Job(Input input) {
		this.input = input;
		this.run();
	}

	@SuppressWarnings("unchecked")
	@Override
	public void run() {
		try {
			if (numberOfRetries >= maxNumberOfRetries)
				throw new MaximumNumberOfRetriesReachedException();
			this.result = this.runJob(input);
		} catch (Throwable t) {
			this.result = (XResult) result.getNewInstance();
			this.result.fail(t);
		}
	}

	protected abstract XResult runJob(Input input);

}

public abstract class Result {

	private Throwable reasonOfFail;

	public abstract Result getNewInstance();

	public void fail(Throwable reasonOfFail) {
		this.reasonOfFail = reasonOfFail;
	}

	public Throwable getReasonOfFail() {
		return reasonOfFail;
	}
}

Does anyone knows a better way of the usage of generic to avoid using

this.result = (XResult) result.getNewInstance();

I was thinking well since I know that XResult has a way to instantiate itself there is no way that the casting would not work., would it?
But it just doesn't feel good using casting, somehow.

Regards,
Johan

[Johan Zahri]

never mind I just did away without using generics..
i guess it's sufficient..

public abstract class Job extends Thread {

	private int numberOfRetries;
	private int maxNumberOfRetries;
	private Input input;
	private Result result;

	public Job(Input input) {
		this.input = input;
		this.run();
	}

	@Override
	public void run() {
		try {
			if (numberOfRetries >= maxNumberOfRetries)
				throw new MaximumNumberOfRetriesReachedException();
			this.result = this.runJob(input);
		} catch (Throwable t) {
			this.result = result.getNewInstance();
			if (result != null)
				this.result.fail(t);
		}
	}

	protected abstract Result runJob(Input input);

}

public abstract class Result {

	private Throwable reasonOfFail;

	public abstract Result getNewInstance();
	
	public void fail(Throwable reasonOfFail) {
		this.reasonOfFail = reasonOfFail;
	}

	public Throwable getReasonOfFail() {
		return reasonOfFail;
	}
}

[Winston Gutkowski]

Johan Zahri wrote:Does anyone knows a better way of the usage of generic to avoid using

this.result = (XResult) result.getNewInstance();

I was thinking well since I know that XResult has a way to instantiate itself there is no way that the casting would not work., would it?
But it just doesn't feel good using casting, somehow.

Well spotted. "Code smell" is a good sense to acquire, so don't ignore it.

And to answer your question: yes there is - make Result generic too.
In this case, it's as simple as:

public abstract class Result<T extends Result> {  
   // other stuff

   public abstract T getNewInstance();
   ...
}

then whatever class extends Result uses the notation:

public final class Failure
   extends Result<Failure>
{...

which results in a getNewInstance() method that returns a Failure.

BTW, generic types, by convention, are usually a single upper-case letter, rather than things like 'XResult'. This is so you can distinguish them from regular class/interface names. The norm is to use 'T' (for 'Type') unless you have a good reason not to, but it's not required. For instance, an interface like Map<K, V> uses its notation to distinguish between 'Keys' and 'Values'.

HIH

Winston

[Winston Gutkowski]

Johan Zahri wrote:never mind I just did away without using generics..
i guess it's sufficient..

Looks fine to me. You don't always have to use generics .

Winston

[Rob Spoor]

Winston Gutkowski wrote:The norm is to use 'T' (for 'Type') unless you have a good reason not to, but it's not required. For instance, an interface like Map<K, V> uses its notation to distinguish between 'Keys' and 'Values'.

Don't forget E for element types, like those of collections and iterables. But keep in mind that the name is always free to choose. For instance, I have one interface with I for the input type and O for the output type, because these make more sense than T and U, for instance. I therefore am more inclined to use either a simple T (for type), or the first letter of what the generic type represents (Key, Value, Element, Input, Output).

[Winston Gutkowski]

Rob Spoor wrote:...or the first letter of what the generic type represents (Key, Value, Element, Input, Output).

Absolutely. I was just trying to say that 'T' is normal unless you can think of something better.

Winston

[Johan Zahri]

Thanks guys for all the input.

Just realized that what I was actually trying to do (quite a distance from the topic.. sigh)
turned out its already implemented in java.util.concurrent.RunnableFuture<Result> :P

As one wise man says..
"reuse!"

Cheers.