+15  A: 

No, it's not overriding it properly. Overriding means you should be able to cope with any valid input to the base class. Consider what would happen if a client did this:

Monitor x = new EmailMonitor();
List<NonEmailAccount> nonEmailAccounts = ...;
x.performMonitor(nonEmailAccounts);

There's nothing in there which should give a compile-time error given your description - but it's clearly wrong.

It sounds to me like Monitor should be generic in the type of account it can monitor, so your EmailMonitor should extend Monitor<EmailAccount>. So:

public abtract class Monitor<T extends MonitorAccount>
{
    ...
    public abstract List<? extends T> performMonitor(
        List<? extends T> accounts);
}

public class EmailMonitor extends Monitor<EmailAccount>
{
    @Override
    public abstract List<? extends EmailAccount> performMonitor(
        List<? extends EmailAccount> accounts)
    {
        // Code goes here
    }
}

You might want to think carefully about the generics in the performMonitor call though - what's the return value meant to signify?

Jon Skeet
You say 'List<? extends EmailAccount>'. Now I can't pass EmailAccount through at all; Was that a typo?. I wanted to check that EmailMonitor always receives a list of EmailAccount and always returns a list of EmailAccount that can be used without dynamic casting.posting my solution now :)
kipkuch
A: 

Here is my own solution. I suspect this is the same thing Jon Skeet was trying to get at... without the typo (see my comment in reply to his answer).

the Monitor.java class:

public abstract class Monitor <T extends MonitorAccount> {
  ...
  public abstract List<T> performMonitor(List<T> accounts);
  ..
}

EmailMonitor.java

public class EmailMonitor extends Monitor<EmailMonitor> {
  ...
  public List<EmailAccount> performMonitor(List<EmailAccount> emailAccounts) {
    ..//logic...logic...logic
    return emailAccounts;
  }
  ...
}

In this configuration, EmailMonitor.performMonitor() will always check at compile time that it receives a list of EmailAccount rather than any of my other types FTPAccount, DBAccount, etc... It's much cleaner than the alternative, which would have been receiving/sending a raw list and then having to coerce it the required type resulting in potential runtime type casting exceptions.

kipkuch
A: 

Hi i have a question!

abstract public class AbstractExpireRule{

// with methos

protected abstract T getvalue();

}

How can we extend this class to return let me say integer or what ever?

public class ExpireDaysFromFirstLogin extends AbstractExpireRule {

@Override
public <Integer> Integer getvalue() {
    return new Integer(5);
}

}

this dosent work

if we take out the generics:

@Override public Integer getvalue() { return new Integer(durationInDays); }

it works but TYPE SAFETY...

Type safety: The return type Integer for getvalue() from the type ExpireDaysFromFirstLogin needs unchecked conversion to conform to T from the type AbstractExpireRule

same like i discard the generics from the abstract class?!

Can some one help...

baze
-1 should be posted as a new question
finnw