My comments [more or less] 'inline':

a) We are forcing end users to create a concrete implementation which isn't desirable
when engine needs to be created dynamically using class by name approach by runtimes. While you
can argue that its just two parenthesis they need to write, but we shouldn't force
tools to write code.

-->

The reason for using...

PricingEngine engine = new BinomialVanillaEngine<Jarrod>(...) {};

... instead of ...

Tree tree = new Jarrod(...);
PricingEngine engine = new BinomialVanillaEngine(tree, ...);

... is that the 'responsibility' for creating a Tree is moved from end user code to library code. An end user only needs to tell which algorithm he/she desires and the library code will do all the magic and calculate all the correct parameters a Tree of such algorithm needs to work properly.

IMHO this is a very good design and object model.
On the other hand, the use of templates in C++ and the tricky counterpart Super Type Token in Java may lead to certain problems:

1. It's difficult to create wrappers when you have templates;

2. Super Type Tokens is an 'advanced' technique which could be easily replaced by something trivial like an enumeration, as Srini mentioned.

======

b) Now lets say user trying out the api the first time and he does
       
      new BinomialVanillaEngine() {}

   which is perfectly legal thing to do. Above is just a compile warning. ....

-->

I've improved error messages and documentation of BinomialVanillaEngine. You just need to hover the mouse over it to obtain the information you need, including an example of usage.

I'd love to see everything being verified at compile time too!
Oh well... this is how Generics works, for good or for bad.

=====

Now lets see how we can address above..
 a) We can create a concrete extensions for each type, for example
    public class JarrowRuddBinomialVanillaEngine extends
     BinomialVanillaEngine<JarrowRudd> { }

-->

This is not convenient for MonteCarlo module. In MC there are classes with 3 (or maybe even 4?) generic parameters. In MC, the following approaches are acceptable:

1. Use Super Type Tokens

MC mc = new MC<MyNumberGenerator,MySampleStrategy,MyDistribution>(...) {};

2. Class as parameters

MC mc = new MC(MyNumberGenerator.class, MySampleStrategy.class, MyDistribution.class, ...);

3. Enumerations

MC mc = new MC(enum1.MyNumberGenerator, enum2.MySampleStrategy, enum3.MyDistribution, ...);

Note: 
In particular, I'm against the use of enumerations because they restrict how the object model can be extended.

IMHO, we should keep the Super Type Token and add constructors which accept Classes as arguments. This change would satisfy 'advanced' users (typically C++ programmers translating their existing code blindly) and Java programmers used to pass Class as arguments without hurting any previous pre-conception.

====

  b) Don't expect users of the api to specify generic type as it is perfectly legal thing not to. When generic type
     is not specified, we should have default type to go with.

-->

Yes, you are correct. It would solve the problem you mentioned in (a).
This is not what the original C++ code does, but we are not running C++ anyway, so... some adjustments are expected.


Thanks a lot for raising this issue! :)

Cheers
-- Richard