Ответ довольно поздний, но вам, возможно, будет интересно узнать это:
Javassist прокси реализованы довольно наивно. В приведенном выше коде Javassist всегда создает прокси-класс со следующими методами:
- Метод для любого переопределяемого метода базового класса
- Два способа (а) получить обработчик прокси (
getHandler
) и (б) установить обработчик прокси (setHandler
)
Имена двух последних методов жестко закодированы Javassist и представлены интерфейсом ProxyObject
. Если вы сейчас создадите прокси-класс прокси-класса, Javassist запланирует создание методов ProxyObject
дважды. Один раз по первому условию и один раз по второму условию.
Этого можно избежать, установив MethodFilter
, который указывает, что не следует переопределять методы ProxyObject
, чтобы javassist создавал методы только по второму условию. Однако это будет означать, что вы больше не сможете установить ProxyObject
для прокси суперкласса без прямого доступа к соответствующему полю через отражение. Поэтому ваш подход, вероятно, самый чистый.
cglib определяет обратные вызовы для каждого класса, а не для каждого экземпляра, так что эта проблема с cglib немного отличается, но приводит к другому конфликту.
Однако, если вы хотите создать прокси-классы, которые не страдают этими недостатками, вас может заинтересовать моя библиотека Byte Buddy , которую я написал после того, как разочаровался в работе с cglib и javassist при работе в угловых случаях , Если вы работаете с генерацией кода во время выполнения, я надеюсь, что это поможет вам предложить некоторую гибкость, которой не хватает другим библиотекам.