PowerMock implementation: bytecode and class loaders

first computer experience with Commodore C64 and typing Basic programs from instruction manuals, early gaming experiences and interest in understanding load commands, transition to Amiga 500 Plus for demo scene scripting and composition, moving to PC era with 486 SX25 and four megabytes of RAM, learning Turbo Pascal and creating 2D Super Mario-inspired games, experimenting with inline assembler in Pascal and reading "The Art of Assembly Programming", reverse engineering games using Win32 disassembler to bypass license checks, studying computer science at Blekinge and Lund University in Sweden, first job at JayWay consultancy firm working on IKEA project in 2005, early adoption of Spring framework and automated testing practices, comparison of old-style EJB with heavy XML configuration versus Spring's lightweight approach, the evolution from XML-based configuration to annotation-based Java EE 5 and 6, creating PowerMock with colleague Jan Kronqvist to mock static methods and final classes, using asm and JavaAssist for bytecode manipulation instead of AspectJ, implementing custom class loaders where each JUnit method executed in different class loader, deep clone module for cloning object graphs between class loaders, tight coupling challenges between PowerMock and Mockito/EasyMock/JUnit versions, transition from EasyMock's record-replay pattern to Mockito's when-then approach, modern preference for avoiding mocks and testing against real cloud environments, optimizing for fast CI/CD pipelines rather than local simulation, structuring code to separate infrastructure concerns from pure business logic, using Java Records as pure data carriers versus adding behavior to records, Clojure-inspired philosophy of decoupling state from behavior and identity, Rich Hickey's "Simple Made Easy" talk and definitions of simple versus easy, multi-methods in functional languages as alternative to polymorphism, domain modeling example with network devices and fiber channel connections, benefits of object-oriented polymorphism for transparent persistence and simple code, avoiding religious adherence to patterns in favor of pragmatic solutions, Maven's stability and opinionated approach versus Gradle's flexibility, reducing external dependencies and Maven plugins in favor of CI/CD automation, the NPM ecosystem's over-modularization compared to Java's more reasonable approach, decline of OSGi hype and return to simpler monolithic architectures, Johan's current work on Occurrent Event Sourcing library and cloud events

Johan Haleby on twitter: @johanhaleby