Proxy call in java

Class Proxy

Proxy provides static methods for creating objects that act like instances of interfaces but allow for customized method invocation. To create a proxy instance for some interface Foo :

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

A proxy class is a class created at runtime that implements a specified list of interfaces, known as proxy interfaces. A proxy instance is an instance of a proxy class. Each proxy instance has an associated invocation handler object, which implements the interface InvocationHandler . A method invocation on a proxy instance through one of its proxy interfaces will be dispatched to the invoke method of the instance’s invocation handler, passing the proxy instance, a java.lang.reflect.Method object identifying the method that was invoked, and an array of type Object containing the arguments. The invocation handler processes the encoded method invocation as appropriate and the result that it returns will be returned as the result of the method invocation on the proxy instance.

• The unqualified name of a proxy class is unspecified. The space of class names that begin with the string «$Proxy» should be, however, reserved for proxy classes.
• The package and module in which a proxy class is defined is specified below.
• A proxy class is final and non-abstract.
• A proxy class extends java.lang.reflect.Proxy .
• A proxy class implements exactly the interfaces specified at its creation, in the same order. Invoking getInterfaces on its Class object will return an array containing the same list of interfaces (in the order specified at its creation), invoking getMethods on its Class object will return an array of Method objects that include all of the methods in those interfaces, and invoking getMethod will find methods in the proxy interfaces as would be expected.
• The ProtectionDomain of a proxy class is the same as that of system classes loaded by the bootstrap class loader, such as java.lang.Object , because the code for a proxy class is generated by trusted system code. This protection domain will typically be granted java.security.AllPermission .
• The Proxy.isProxyClass method can be used to determine if a given class is a proxy class.

Given a proxy instance proxy and one of the interfaces, Foo , implemented by its proxy class, the following expression will return true:

Package and Module Membership of Proxy Class

1. If all the proxy interfaces are in exported or open packages:
   1. if all the proxy interfaces are public, then the proxy class is public in an unconditionally exported but non-open package. The name of the package and the module are unspecified.
   2. if at least one of all the proxy interfaces is non-public, then the proxy class is non-public in the package and module of the non-public interfaces. All the non-public interfaces must be in the same package and module; otherwise, proxying them is not possible.
   1. if all the proxy interfaces are public, then the proxy class is public in a non-exported, non-open package of dynamic module. The names of the package and the module are unspecified.
   2. if at least one of all the proxy interfaces is non-public, then the proxy class is non-public in the package and module of the non-public interfaces. All the non-public interfaces must be in the same package and module; otherwise, proxying them is not possible.

   Note that if proxy interfaces with a mix of accessibilities — for example, an exported public interface and a non-exported non-public interface — are proxied by the same instance, then the proxy class’s accessibility is governed by the least accessible proxy interface.

   Note that it is possible for arbitrary code to obtain access to a proxy class in an open package with setAccessible , whereas a proxy class in a non-open package is never accessible to code outside the module of the proxy class.

   Throughout this specification, a «non-exported package» refers to a package that is not exported to all modules, and a «non-open package» refers to a package that is not open to all modules. Specifically, these terms refer to a package that either is not exported/open by its containing module or is exported/open in a qualified fashion by its containing module.

   Dynamic Modules

   A dynamic module is a named module generated at runtime. A proxy class defined in a dynamic module is encapsulated and not accessible to any module. Calling Constructor.newInstance(Object. ) on a proxy class in a dynamic module will throw IllegalAccessException ; Proxy.newProxyInstance method should be used instead.

   A dynamic module can read the modules of all of the superinterfaces of a proxy class and the modules of the classes and interfaces referenced by all public method signatures of a proxy class. If a superinterface or a referenced class or interface, say T , is in a non-exported package, the module of T is updated to export the package of T to the dynamic module.

   Methods Duplicated in Multiple Proxy Interfaces

   When two or more proxy interfaces contain a method with the same name and parameter signature, the order of the proxy class’s interfaces becomes significant. When such a duplicate method is invoked on a proxy instance, the Method object passed to the invocation handler will not necessarily be the one whose declaring class is assignable from the reference type of the interface that the proxy’s method was invoked through. This limitation exists because the corresponding method implementation in the generated proxy class cannot determine which interface it was invoked through. Therefore, when a duplicate method is invoked on a proxy instance, the Method object for the method in the foremost interface that contains the method (either directly or inherited through a superinterface) in the proxy class’s list of interfaces is passed to the invocation handler’s invoke method, regardless of the reference type through which the method invocation occurred.

   If a proxy interface contains a method with the same name and parameter signature as the hashCode , equals , or toString methods of java.lang.Object , when such a method is invoked on a proxy instance, the Method object passed to the invocation handler will have java.lang.Object as its declaring class. In other words, the public, non-final methods of java.lang.Object logically precede all of the proxy interfaces for the determination of which Method object to pass to the invocation handler.

   Note also that when a duplicate method is dispatched to an invocation handler, the invoke method may only throw checked exception types that are assignable to one of the exception types in the throws clause of the method in all of the proxy interfaces that it can be invoked through. If the invoke method throws a checked exception that is not assignable to any of the exception types declared by the method in one of the proxy interfaces that it can be invoked through, then an unchecked UndeclaredThrowableException will be thrown by the invocation on the proxy instance. This restriction means that not all of the exception types returned by invoking getExceptionTypes on the Method object passed to the invoke method can necessarily be thrown successfully by the invoke method.

   Источник

   Динамический прокси Java: что это и как им пользоваться?

   Ну что ж до Нового года и старта десятого потока «Разработчик Java» осталось совсем шуть-шуть. Так что у нас остался один открытый урок, который мы подготавливаем для публикации и сегодняшняя заметка, из которой вы узнаете о динамическом прокси Java: что это такое, когда и как его использовать в коде.

   Прокси — это шаблон проектирования. Мы создаем и используем его для добавления и изменения функционала уже существующих классов. В таком случае, прокси-объект применяется вместо исходного. Обычно он использует тот же метод, что и оригинальный, и в Java прокси-классы расширяют исходные. Прокси может вызвать метод исходного объекта, так как у него есть дескриптор оригинала.

   Таким образом, прокси-классы удобно реализуют многие вещи:

   

   • логирование старта и остановки метода;
   • дополнительную проверку аргументов;
   • имитацию поведения исходного класса;
   • реализацию отложенной инициализации затратных ресурсов;

   Все это происходит без изменений оригинального кода класса. Полный список не ограничивается примерами выше, они лишь его малая часть.

   На практике, прокси-класс напрямую не реализует функционал. Следуя принципу единственной ответственности, прокси-класс непосредственно выполняет только проксирование, а изменение поведения реализуется в обработчиках. При вызове прокси-объекта вместо исходного, сам прокси решает, вызвать ли оригинальный метод или какие-то обработчики. Обработчик может выполнить как собственную задачу, так и обратиться к оригинальному методу.

   Хоть шаблон прокси применяется не только для создания прокси-объекта и класса в среде выполнения, в Java это особенно интересная тема. В этой статье я фокусируюсь именно на таких прокси.

   Это сложная тема, которая требует использования класса отражения, или манипулирования байт-кодом, или компиляции Java-кода, сгенерированного динамически. А может всего и сразу. Чтобы новый класс не был доступен в качестве байт-кода во время исполнения, потребуются сгенерированный байт-код и загрузчик классов для загрузки байт-кода. Для создания байт-кода, используйте cglib, bytebuddy или встроенный компилятор Java.

   Важность разделения ответственностей, в нашем случае, становится ясна, стоит лишь подумать о прокси-классах и вызываемых ими обработчиках. Прокси-класс генерируется во время выполнения, но вызванные им обработчики могут быть добавлены в обычный исходный код и скомпилированы с остальной программой.

   Как этим пользоваться в нашем коде?

   Самое простое — использовать java.lang.reflect.Proxy , который является частью JDK. Этот класс может создать прокси-класс или напрямую его инстанс. Пользоваться прокси, встроенным в Java, очень просто. Все что нужно — реализовать java.lang.InvocationHandler , чтобы прокси-объект мог его вызывать. Интерфейс InvocationHandler крайне прост и содержит только один метод: invoke() . При его вызове, аргументы содержат проксируемый оригинальный объект, вызванный метод (как отражение объекта Method ) и массив объектов исходных аргументов. Фрагмент кода ниже демонстрирует применение:

   package proxy; import java.lang.reflect.InvocationHandler; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; import java.lang.reflect.Proxy; public class JdkProxyDemo < interface If < void originalMethod(String s); >static class Original implements If < public void originalMethod(String s) < System.out.println(s); >> static class Handler implements InvocationHandler < private final If original; public Handler(If original) < this.original = original; >public Object invoke(Object proxy, Method method, Object[] args) throws IllegalAccessException, IllegalArgumentException, InvocationTargetException < System.out.println("BEFORE"); method.invoke(original, args); System.out.println("AFTER"); return null; >> public static void main(String[] args)< Original original = new Original(); Handler handler = new Handler(original); If f = (If) Proxy.newProxyInstance(If.class.getClassLoader(), new Class[] < If.class >, handler); f.originalMethod("Hallo"); > >

   Для вызова оригинального метода исходного объекта, обработчику необходим доступ к нему. Что не предоставлено реализацией прокси Java. Вам понадобится самостоятельно передать аргумент инстансу обработчика в коде. (Обратите внимание на объект (обычно с названием proxy), который передается в качестве аргумента вызываемому обработчику. Это прокси-объект, который отражение Java генерирует динамически, а не тот объект, что мы хотим проксировать.) Таким образом, вы можете использовать как отдельные объекты-обработчики для каждого исходного класса, так и общий объект, который знает, как вызвать оригинальный объект, если для этого вообще есть какой-либо метод.

   В особом случае, вы можете создать обработчик вызова и прокси интерфейса без оригинального объекта. Более того, класс для реализации интерфейса в исходном коде — не требуется. Его реализует динамически созданный прокси-класс.

   Если же проксируемый класс не реализует интерфейс, стоит задуматься об использовании какой-либо иной реализации прокси.

   Ждём ваши комментарии и вопросы. Как всегда или тут, или можно зайти к Виталию на день открытых дверей.

   Источник