Those limitations are a little annoying but I'm not sure how they're preventing you from doing what you want to do, and having top-level statics wouldn't limit someone from just sneaking global state in there either.

    @Test
    public void testSomeMethod_FromStatic() {
        StaticWrapper1 staticWrapper = new StaticWrapper1();
        int mockInput = 1;
        RegularClass rc = new RegularClass();
        int expected = 2;

        int ret = staticWrapper.someStaticClass.someMethod(rc, mockInput);

        verify(staticWrapper.someStaticClass, times(1)).someMethod(rc, mockInput);
        assertEquals(expected, ret);
    }


    public class StaticWrapper1 {
        static class StaticClass {
            public int someMethod(RegularClass foo, int val){
                return foo.someAddMethod(val);
                /* it's not practical to chain, eg
                   staticWrapper2.someAddMethod(foo, val);
                   because you end up with circular dependencies or passing large numbers of deps around, which you can't verify in tests anyway */
            }
        }
    }

You cant do this (verify the static call) by default nor anything more complicated than this (with Mockito Static mocking) because JUnit cant track deps through statics for testing. If you have multiple static objects that have static methods, you end up with brittle chains of instances that might need to refer to (either passed in or member instances of wrappers) just to call other static methods. This is inferior to PHPUnit.

Making syntactical boilerplate "just because", which also requires instantiation breaking DI (ostensibly, all you have to do is boot up Spring IoC container and it's there are runtime), is inferior to PHP.

Maybe one day Spring will be baked into Java, but that's a one-ton runtime workaround for a small mistake in the core philosophy, ie you can put a non-static function around a static function and treat it as the static, so it's a JVM problem. Pushing explicit instancing to the code is bad design from a makeshift solution to get Java working on older platforms, quickly. Now java does prechecking of memory anyway, so the way you have to do static implementation is an extraneous legacy limitation.

Right, I mean, if you need to mock it a singleton would be a better choice; that's kind of the point of the pattern. Personally, though, I feel like if you frequently find yourself needing to mock these static classes, then they're not really as effective at avoiding statefulness as you claim -- if they're side effect-free, it should be safe to just use the implementation.

You need to mock them because you are asserting that it is the correct thing to use. Verification testing has nothing to do with state, per se. Having a static instance a wrapper just to use another static is java forcing unnecessary state. Forcing a singleton to instance another singleton at runtime is idiotic, which is why spring proponents avoid it and java is still a syntactical dinosaur. When we see proper modules (including static refs), java will be better fir it.

PHP is better with how it deals with statics today, which bleeds into other areas like testing.