Проверка ограничений Java не работает для параметров

В дополнение к другим ответам и тому факту, что вы знаете о существовании прокси-серверов AOP, позвольте мне указать вам на соответствующая глава в документации Spring, в которой упоминается проблема самовызова с прокси-серверами AOP, с которой вы столкнулись:

public class Main {

    public static void main(String[] args) {
        ProxyFactory factory = new ProxyFactory(new SimplePojo());
        factory.addInterface(Pojo.class);
        factory.addAdvice(new RetryAdvice());

        Pojo pojo = (Pojo) factory.getProxy();
        // this is a method call on the proxy!
        pojo.foo();
    }
}

fun main() {
    val factory = ProxyFactory(SimplePojo())
    factory.addInterface(Pojo::class.java)
    factory.addAdvice(RetryAdvice())

    val pojo = factory.proxy as Pojo
    // this is a method call on the proxy!
    pojo.foo()
}

Здесь важно понимать, что клиентский код внутри метода main(..) класса Main имеет ссылку на прокси. Это означает, что вызовы метода для этой ссылки на объект являются вызовами прокси. В результате прокси-сервер может делегировать полномочия всем перехватчикам (советам), которые имеют отношение к этому конкретному вызову метода. Однако, как только вызов, наконец, достигает целевого объекта (в данном случае ссылки SimplePojo), любые вызовы методов, которые он может сделать для самого себя, такие как this.bar() или this.foo(), будут вызываться для ссылки this, а не прокси. Это имеет важные последствия. Это означает, что самостоятельный вызов не приведет к тому, что совет, связанный с вызовом метода, получит возможность выполниться.

-- https://docs.spring.io/spring/docs/5.2.3.RELEASE/spring-framework-reference/core.html#aop-understanding-aop-proxy

В следующем абзаце предлагаются два решения (а на самом деле три, но переход на AspectJ в данном конкретном случае может оказаться громоздким):

Хорошо, так что же с этим делать? Наилучший подход (термин «лучший» здесь используется в широком смысле) — это рефакторинг вашего кода таким образом, чтобы не происходило самовызова. Это требует некоторой работы с вашей стороны, но это лучший, наименее инвазивный подход. Следующий подход абсолютно ужасен, и мы не решаемся указать на него именно потому, что он так ужасен. Вы можете (как это ни болезненно для нас) полностью связать логику вашего класса со Spring AOP, как показано в следующем примере:

public class SimplePojo implements Pojo {

    public void foo() {
        // this works, but... gah!
        ((Pojo) AopContext.currentProxy()).bar();
    }

    public void bar() {
        // some logic...
    }
}

class SimplePojo : Pojo {

    fun foo() {
        // this works, but... gah!
        (AopContext.currentProxy() as Pojo).bar()
    }

    fun bar() {
        // some logic...
    }
}

Это полностью связывает ваш код с АОП Spring и позволяет самому классу осознавать тот факт, что он используется в контексте АОП, что бросает вызов АОП. Также требуется дополнительная настройка при создании прокси, как показано в следующем примере:

public class Main {

    public static void main(String[] args) {
        ProxyFactory factory = new ProxyFactory(new SimplePojo());
        factory.addInterface(Pojo.class);
        factory.addAdvice(new RetryAdvice());
        factory.setExposeProxy(true);

        Pojo pojo = (Pojo) factory.getProxy();
        // this is a method call on the proxy!
        pojo.foo();
    }
}

fun main() {
    val factory = ProxyFactory(SimplePojo())
    factory.addInterface(Pojo::class.java)
    factory.addAdvice(RetryAdvice())
    factory.isExposeProxy = true

    val pojo = factory.proxy as Pojo
    // this is a method call on the proxy!
    pojo.foo()
}

Наконец, следует отметить, что AspectJ не имеет этой проблемы с самовызовом, потому что это не AOP-инфраструктура на основе прокси.

-- https://docs.spring.io/spring/docs/5.2.3.RELEASE/spring-framework-reference/core.html#aop-understanding-aop-proxy

Проверка Spring вызывается, когда управляемый компонент вызывает другой управляемый компонент.

Однако контекст Spring не знает о вызовах между методами внутри одного и того же bean-компонента, т.е. внутриbean, а не между bean-компонентами, поэтому @Validation не имеет никакого влияния.

Одним из простых решений является перемещение метода-оболочки из класса в служебный метод, например:

public static void methodA(MyService myService) {
    myService.methodB("");
}

В Spring нет аннотации @Validation. Я думаю, вы имели в виду @Validated.

Для проверки параметров Spring создает своего рода прокси, используя CGLIB. Это механизм, аналогичный тому, что Spring использует для транзакций. Spring добавляет этот код, только если ваш класс MyServiceImpl вызывается из другого класса, т. е. когда поток управления пересекает границу между двумя классами. Когда вы вызываете свой methodB из другого класса, Spring добавляет код проверки. Когда вы вызываете его из того же класса, Spring не добавляет кода, и поэтому проверка не запускается.