Класс Proxy

    InvocationHandler handler = new MyInvocationHandler(...);
    Foo f = (Foo) Proxy.newProxyInstance(Foo.class.getClassLoader(),
                                         new Class<?>[] { Foo.class },
                                         handler);

Прокси-класс — это класс, создаваемый во время выполнения, который реализует указанный список интерфейсов, называемых прокси-интерфейсами. Прокси-экземпляр — это экземпляр прокси-класса. Каждый прокси-экземпляр имеет связанный объект обработчика вызовов, реализующий интерфейс InvocationHandler. Вызов метода на прокси-экземпляре через один из его прокси-интерфейсов будет перенаправлен в метод invoke обработчика вызовов этого экземпляра с передачей прокси-экземпляра, объекта java.lang.reflect.Method, идентифицирующего вызванный метод, и массива типа Object, содержащего аргументы. Обработчик вызовов обрабатывает закодированный вызов метода соответствующим образом, и возвращенный им результат возвращается в качестве результата вызова метода на прокси-экземпляре.

Прокси-класс обладает следующими свойствами:

• Неполное имя прокси-класса не определено. Пространство имен классов, начинающихся со строки "$Proxy", тем не менее, должно быть зарезервировано для прокси-классов.
• Пакет и модуль, в которых определен прокси-класс, указаны ниже.
• Прокси-класс является final и неабстрактным.
• Прокси-класс расширяет класс java.lang.reflect.Proxy.
• Прокси-класс реализует в точности те интерфейсы, которые были указаны при его создании, и в том же порядке. Вызов getInterfaces для его объекта Class вернет массив, содержащий тот же список интерфейсов (в порядке, указанном при его создании), вызов getMethods для его объекта Class вернет массив объектов Method, включающий все методы этих интерфейсов, а вызов getMethod найдет методы в прокси-интерфейсах ожидаемым образом.
• ProtectionDomain прокси-класса совпадает с доменом защиты системных классов, загруженных загрузчиком классов начальной загрузки, таких как java.lang.Object.
• Метод Proxy.isProxyClass можно использовать для определения того, является ли указанный класс прокси-классом.

Прокси-экземпляр обладает следующими свойствами:

• Для заданного прокси-экземпляра proxy и одного из интерфейсов Foo, реализованных его прокси-классом, следующее выражение вернет true:

      proxy instanceof Foo
  

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

      (Foo) proxy
  

• Каждый прокси-экземпляр имеет связанный обработчик вызовов, переданный в его конструктор. Статический метод Proxy.getInvocationHandler возвращает обработчик вызовов, связанный с прокси-экземпляром, переданным в качестве аргумента.
• Вызов метода интерфейса на прокси-экземпляре будет закодирован и перенаправлен в метод invoke обработчика вызовов, как описано в документации к этому методу.
• Прокси-интерфейс может определять метод по умолчанию или наследовать его от своего суперинтерфейса прямо или косвенно. Обработчик вызовов может вызвать метод по умолчанию прокси-интерфейса путем вызова InvocationHandler::invokeDefault.
• Вызов методов hashCode, equals или toString, объявленных в java.lang.Object, на прокси-экземпляре будет закодирован и перенаправлен в метод invoke обработчика вызовов точно так же, как кодируются и перенаправляются вызовы методов интерфейса, как описано выше. Классом объявления объекта Method, переданного в invoke, будет java.lang.Object. Другие открытые методы прокси-экземпляра, унаследованные от java.lang.Object, не переопределяются прокси-классом, поэтому вызовы этих методов ведут себя так же, как и для экземпляров класса java.lang.Object.

Принадлежность прокси-класса к пакету и модулю

1. Если все прокси-интерфейсы находятся в экспортируемых или открытых пакетах:
   1. если все прокси-интерфейсы являются public, то прокси-класс является public в безоговорочно экспортируемом, но неоткрытом пакете. Имя пакета и имя модуля не определены.
   2. если хотя бы один из всех прокси-интерфейсов является non-public, то прокси-класс является non-public в пакете и модуле непубличных интерфейсов. Все непубличные интерфейсы должны находиться в одном и том же пакете и модуле; в противном случае создание прокси для них невозможно.
2. Если хотя бы один прокси-интерфейс находится в пакете, который является неэкспортируемым и неоткрытым:
   1. если все прокси-интерфейсы являются public, то прокси-класс является public в неэкспортируемом, неоткрытом пакете динамического модуля. Имена пакета и модуля не определены.
   2. если хотя бы один из всех прокси-интерфейсов является non-public, то прокси-класс является non-public в пакете и модуле непубличных интерфейсов. Все непубличные интерфейсы должны находиться в одном и том же пакете и модуле; в противном случае создание прокси для них невозможно.

Обратите внимание: если прокси-интерфейсы со смешанной доступностью — например, экспортируемый открытый интерфейс и неэкспортируемый непубличный интерфейс — проксируются одним и тем же экземпляром, то доступность прокси-класса определяется наименее доступным прокси-интерфейсом.

Обратите внимание, что произвольный код может получить доступ к прокси-классу в открытом пакете с помощью setAccessible, тогда как прокси-класс в неоткрытом пакете никогда не доступен коду вне модуля прокси-класса.

В этой спецификации под «неэкспортируемым пакетом» понимается пакет, который не экспортирован во все модули, а под «неоткрытым пакетом» — пакет, который не открыт для всех модулей. В частности, эти термины относятся к пакету, который либо не экспортирован/открыт содержащим его модулем, либо экспортирован/открыт содержащим его модулем с квалификацией.

Динамические модули

Динамический модуль — это именованный модуль, генерируемый во время выполнения. Прокси-класс, определенный в динамическом модуле, инкапсулирован и недоступен ни для одного модуля. Вызов Constructor.newInstance(Object...) для прокси-класса в динамическом модуле выбросит IllegalAccessException; вместо этого следует использовать метод Proxy.newProxyInstance.

Динамический модуль может читать модули всех суперинтерфейсов прокси-класса, а также модули классов и интерфейсов, на которые ссылаются все сигнатуры открытых методов прокси-класса. Если суперинтерфейс или упоминаемый класс/интерфейс, например T, находится в неэкспортируемом пакете, модуль класса/интерфейса T обновляется для экспорта пакета T в динамический модуль.

Методы, дублирующиеся в нескольких прокси-интерфейсах

Если два или более прокси-интерфейса содержат метод с одинаковым именем и сигнатурой параметров, порядок интерфейсов прокси-класса становится существенным. При вызове такого дублирующегося метода на прокси-экземпляре объект Method, переданный обработчику вызовов, не обязательно будет тем, чей класс объявления совместим по присваиванию с ссылочным типом интерфейса, через который был вызван метод прокси. Это ограничение существует потому, что соответствующая реализация метода в сгенерированном прокси-классе не может определить, через какой интерфейс она была вызвана. Поэтому при вызове дублирующегося метода на прокси-экземпляре объект Method для метода из самого первого интерфейса в списке интерфейсов прокси-класса, содержащего этот метод (напрямую или унаследованного через суперинтерфейс), передается в метод invoke обработчика вызовов независимо от ссылочного типа, через который произошел вызов метода.

Если прокси-интерфейс содержит метод с тем же именем и сигнатурой параметров, что и методы hashCode, equals или toString класса java.lang.Object, то при вызове такого метода на прокси-экземпляре объект Method, переданный обработчику вызовов, будет иметь java.lang.Object в качестве класса объявления. Иными словами, открытые не-final методы класса java.lang.Object логически предшествуют всем прокси-интерфейсам при определении того, какой объект Method передать обработчику вызовов.

Обратите внимание также, что при диспетчеризации дублирующегося метода в обработчик вызовов метод invoke может генерировать только проверяемые типы исключений, которые совместимы по присваиванию с одним из типов исключений в предложении throws метода во всех прокси-интерфейсах, через которые он может быть вызван. Если метод invoke выбрасывает проверяемое исключение, не совместимое по присваиванию ни с одним из типов исключений, объявленных методом в одном из прокси-интерфейсов, через которые он может быть вызван, то при вызове на прокси-экземпляре будет выброшено непроверяемое исключение UndeclaredThrowableException. Это ограничение означает, что не все типы исключений, возвращаемые вызовом getExceptionTypes для объекта Method, переданного в метод invoke, обязательно могут быть успешно выброшены методом invoke.