Hmm... an unusual question. The only reason I can think to do this is if you don't trust the authors of overriding methods to write their code correctly. (Which I think may be a healthy level of paranoia in many work environments.) If that's the case, here's what I might do:
<code><pre>class foo {
public foo() {}
public final void hello() {
System.out.println("Hello ");
hello2();
}
protected void hello2() {}
}
class bar extends foo {
public bar() { }
protected void hello2() {
System.out.println("World");
}
}</pre></code>
By making hello() final in foo, we can force any subclasses to override hello2() instead. Anyone calling hello() on an object derived from foo will execute the foo.hello() method, and then whatever hello2() has been overridden to. Of course, your co-workers can still get around this by executing hello2() directly if they wish - but note that hello2() is protected while hello() is public. Any other classes not inheriting from foo (and outside the current package) will only be able to use hello(), which I gather is what you want.
If you do something like this,
you should probably make it clear in the javadoc comments that subclasses should override hello2() in order to add functionality to hello(). Otherwise your co-workers may just decide you don't have any idea what you're doing. Of course, your co-workers may not read the javadoc comments (which is probably why you don't trust them to override your code correctly) but at least this way you can claim the moral high groud. "What do you mean my code doesn't work? Didn't you read the documentation I thoughtfully provided?"