Class InlineBytecodeGenerator

    • Field Detail

      • EXCLUDES

        static final java.util.Set<java.lang.Class<?>> EXCLUDES
      • instrumentation

        private final java.lang.instrument.Instrumentation instrumentation
      • byteBuddy

        private final net.bytebuddy.ByteBuddy byteBuddy
      • mockTransformer

        private final net.bytebuddy.asm.AsmVisitorWrapper mockTransformer
      • getModule

        private final java.lang.reflect.Method getModule
      • canRead

        private final java.lang.reflect.Method canRead
      • redefineModule

        private final java.lang.reflect.Method redefineModule
      • lastException

        private volatile java.lang.Throwable lastException
    • Method Detail

      • preload

        private static void preload()
        Mockito allows to mock about any type, including such types that we are relying on ourselves. This can cause a circularity: In order to check if an instance is a mock we need to look up if this instance is registered in the mocked set. But to look up this instance, we need to create key instances that rely on weak reference properties. Loading the later classes will happen before the key instances are completed what will cause Mockito to check if those key instances are themselves mocks what causes a loop which results in a circularity error. This is not normally a problem as we explicitly check if the instance that we investigate is one of our instance of which we hold a reference by reference equality what does not cause any code execution. But it seems like the load order plays a role here with unloaded types being loaded before we even get to check the mock instance property. To avoid this, we are making sure that crucuial JVM types are loaded before we create the first inline mock. Unfortunately, these types dependant on a JVM's implementation and we can only maintain types that we know of from well-known JVM implementations such as HotSpot and extend this list once we learn of further problematic types for future Java versions. To allow users to whitelist their own types, we do not also offer a property that allows running problematic tests before a new Mockito version can be released and that allows us to ask users to easily validate that whitelisting actually solves a problem as circularities could also be caused by other problems.
      • assureInitialization

        private static void assureInitialization​(java.lang.Class<?> type)
      • triggerRetransformation

        private <T> void triggerRetransformation​(java.util.Set<java.lang.Class<?>> types,
                                                 boolean flat)
      • assureCanReadMockito

        private void assureCanReadMockito​(java.util.Set<java.lang.Class<?>> types)
      • checkSupportedCombination

        private <T> void checkSupportedCombination​(boolean subclassingRequired,
                                                   MockFeatures<T> features)
      • addInterfaces

        private void addInterfaces​(java.util.Set<java.lang.Class<?>> types,
                                   java.lang.Class<?>[] interfaces)
      • transform

        public byte[] transform​(java.lang.ClassLoader loader,
                                java.lang.String className,
                                java.lang.Class<?> classBeingRedefined,
                                java.security.ProtectionDomain protectionDomain,
                                byte[] classfileBuffer)
        Specified by:
        transform in interface java.lang.instrument.ClassFileTransformer