Java vs. C#/.NET

C# has the var keyword. Java has no equivalent.

C# has extension methods. Java has no equivalent.

.NET has LINQ. Java has no equivalent.

C# has the delegate keyword. Java 8 has the @FunctionalInterface annotation for interfaces with a single method

C# allows methods to reflect on type parameters. Java does not due to "type erasure."

Visual Studio vs. Eclipse

Found that in Eclipse often you have to save all files before type mismatch errors go away. VS is smarter, i.e. you don't have to save files before type resolution kicks in.

more to come...

Java Servlets vs. ASP.NET Applications

When comparing System.Web.HTTPApplication to the Java Servlet, it would appear that the former has advantages in terms of thread safety. Not sure if this comes with a corresponding performance disadvantage...

For instance K. Scott Allen says "one request at a time is associated with an HttpApplication object" and gives an example of an instance member being set to.

By contrast JavaWorld gives an example of how setting instance members is definitely not thread safe, with the only way out being using the now-deprecated SingleThreadInterface (does ASP.NET use a similar mechanism implicitely?) or not using instance methods at all (or using workarounds like synchronization).

Factories vs. Activator

Get the error "the type parameter cannot be used with type arguments" when attempting to add a constraint such as where S : BaseClass<T<U>>

So I guess this is where factories come in. Otherwise I could just use Activator<T>.CreateInstance for all these nested parameter types, which C# doesn't support...

Question #1: Where go the events?

I.e. UI events. If MVVM prescribes a no-codebehind vision, where are the UI events (e.g. on-change states of datagrids, etc.) handled? Declarative triggers? MVP appears to make allowance for the events (commands are handled well by MVVM). Can we live without UI events? More specifically, can we do without handling them in the codebehind. The workaround I suppose is to use custom attached behaviors or EventSetters.

Tradeoff #1 - DRY vs. SRP

DRY vs. SRP

I think the conflict is clear. A method or class doesn't quite fit a new use case. Rather than extending the class or method a little bit, it might be better to clone it and change it to fit the new circumstance. Sure there's some repeated code between the two methods, the original and the spin-off, but you've stuck to SRP and I believe the result is more maintainable code. And in the future when you have time you can modularize and refactor the shared code.