Why Java folks should stop looking down on C#: differences in similarities

CLR processes are just processes. They're integrated into a native VM, they are capable of code sharing and they use more compact in-memory representations of built-in types. CLR was designed to run on machines we're running it on, not with a goal of selling more of "big iron". CRL is great for general purpose software development, without cowardly "long-running" or "on dedicated box" prefixes attached.

Version 1, you import a third party library:

    public class ThirdParty
    {
        public void calculateAndPrintResult()
        {
            System.out.println("1");
        }
    }

    public class Mine extends ThirdParty
    {
        public void calculateAndPrintResult()
        {
            super.calculateAndPrintResult();
            this.printResult();
        }

        protected void printResult()
        {
            System.out.println("2");
        }

        public static void main(String[] arguments)
        {
            Mine mine = new Mine();
            mine.calculateAndPrintResult();
            // Prints 1, 2
        }
    }

    public class ThirdParty
    {
        public void calculateAndPrintResult()
        {
            this.printResult();
        }

        protected void printResult()
        {
            System.out.println("1");
        }
    }

    public class Mine extends ThirdParty
    {
        public void calculateAndPrintResult()
        {
            super.calculateAndPrintResult();
            this.printResult();
        }

        protected void printResult()
        {
            System.out.println("2");
        }

        public static void main(String[] arguments)
        {
            Mine mine = new Mine();
            mine.calculateAndPrintResult();
            // Prints 2 ! (wrong)
        }
    }

It can take a lot of work tracking down this kind of bug.

When you finally realize this type of issue arises despite everyone following "best practice" OOP, then the reason is because "best practice" OOP is not actually best practice.

Implementation inheritance breaks encapsulation. It creates an intimate entanglement between the internal implementation details of the super- and sub-classes. Every time you extend a class or override a method that wasn't explicitly and carefully designed to be subclassed and overridden safely, you are _writing hacky code_.

There are, of course, places for hacky code. If you understand why something is hacky and feel it's a worthwhile trade-off then by all means you should be able to do it. Java, though, encourages people to pepper their code with such hacks before they have learned why they shouldn't.

In practice a lot of developers end up using open source build tools like nant and rake in preference to msbuild as they tend to be more flexible in other build environments like TeamCity/Hudson.

Microsoft has pushed Silverlight as a .NET vm that runs on Mac, with a smaller framework library. So far, this has met will little traction. I don't think it will encourage MS to push this further and wider.