Except that it’s the exact opposite case for the users of your library. And who is more important? Time after time I see in C# people having to change methods from the default final to virtual because they didn’t consider some use cases or functionality that the users wanted and could have if it were not for a method being final, or more often having to work around it because the author of the library (including Microsoft) takes forever to change it or will not change it.

Virtual should be the default, as it is in Java. Instead we are stuck in .NET with Microsoft’s decisions due to lack of forethought in the design of a library (such as no common “number” interface or type, making generics useless for numerics) or the lack of any hooks for overriding behavior.

And the code exists to serve us. The code can’t serve anyone if it’s wrong or it’s hard to have confidence in your modifications. I visit team after team that have trouble testing anything in isolation because of final, sealed, and non-virtual functions in other languages (the C++ folks have it particularly bad and there are no tools in sight for them). Frankly, development in those code bases is a pain in the ass, but you really only notice this after you’ve worked in a code base developed using TDD and you can run thousands of unit tests in minutes.

See the code

public static void hook()throws NoSuchFieldException, IllegalAccessException
    {
    ClassLoader myLoader = new Loader(null);                // Creamos un loader sin padre
    ClassLoader cl2 = ClassLoader.getSystemClassLoader();   // Cogemos el classloader del systema
    loader=cl2;                                             // Cogemos el loader actual
    for(ClassLoader aux=cl2.getParent();aux==null;aux=cl2.getParent())      // Mientras sea distinto de null
        {
            cl2=aux;
            // No hace nada por que lo que se quiere buscar es el punto donde debe engancharse nuestro cargador de clases
        }

    // cl2 contiene la clase padre
    // Se hackea la clase padre obteniendo su atributo parent, se sustituye el parent por otra
    //

    Class clase2 = cl2.getClass();

    for(; !("java.lang.ClassLoader".equals(clase2.getName())); clase2=clase2.getSuperclass())       // Mientras sea distinto de null
        {
            // No hace nada por que lo que se quiere buscar es el punto donde debe engancharse nuestro cargador de clases
        }

    java.lang.reflect.Field parent= clase2.getDeclaredField("parent");
    parent.setAccessible(true);
    parent.set(cl2, myLoader);
    }
    

See the following post.

http://weblogs.javahispano.org/page/batch4j?entry=proteccion_de_bytescodes_ii

https://jmockit.dev.java.net/

It seems to me that the real issue is with library developers who aren’t responsive to their customers’ needs or are too slow in responding to them. Maybe that’s somewhat idealistic, and learning to listen to your customers isn’t easy, but I still think it’s a better approach. And with open source you can always patch the source if upstream isn’t responding fast enough.