I know cglib proxying works by subclassing target class and overriding target class' methods.
Can anyone tell how exactly dynamic proxy works?
I know it uses interface for proxying, but how exactly method invokation happens through proxy?
Using Proxy.newProxyInstance() you can ask for a proxy implementing required interfaces. You need to pass an InvocationHandler too, which is called every time you call any proxy method. Then, in your handler, you know which method is called and its parameters, so you can do what you desire, including using a target object.
How does Java handle this? Well, it's done natively, just as the internals of reflection and a lot of basic functionality. So, you can emulate this behavior using plain Java.
Extended info here.
Related
Is it possible to access a method in different package but same project without making the method public or inheritance? I'm looking for something similar to friendly assemblies in C#.
Is it possible to access a method in different package but same project without making the method public or inheritance?
Sortof, yes - you can use reflection to get the method that you're after, call setAccessible(true) on the method to suppress the access checks, then invoke it from wherever you like.
But...
I'm looking for something similar to friendly assemblies in C#.
This isn't it, a similar feature simply doesn't exist in the Java language. The above reflection trick should really be treated as nothing more than a hack, and certainly not something you'd want to use in production code unless there really was no other feasible option.
I am working on an API for a software so my users can extend it without modifying the source code. But, I want only certain functions to be accessed by certain classes for security reasons. Is there anyway to do this? Also, I have no code because I have no idea on how to do this.
Thanks! -Trent
I have two thoughts on this, one is that you can look at how Minecraft Forge created their plugin API.
Another way is to have a limited API between your core code and the actual plugins, but, you need to be careful of the platform. For example, if you write the core application in Java or C#, then I can use Aspect Oriented Programming (AOP) to bypass your security and have my code change the behavior of yours.
If you use functional programming (FP) languages, then you can protect more from this type of approach, if you also are not using languages on these platforms, but they are not perfect.
So, there is a trade-off between power and convenience, so how useful do you want your application to be, and how secure?
One possible solution that may work is if you go with something similar to Minecraft, though I doubt they do this, but, give a stub application to the user. They can extend it with plugins, and the interface functions they can modify are in the stub. When the program starts, the plugins are loaded, and the interface may be modified or extended, but, then the core program is pulled down and put into the stub, and then the actual program runs. The core program can be recompiled and manipulated so method names are changed, so reflection is harder to use, but taking this approach, and doing it well, would be hard.
BTW, I like Alex T's response, I just gave different terms to some of his, such as AOP instead of reflection and immutability is part of FP.
You mention jar, which means you are using something that runs on a JVM, so you may want to read up on AspectJ, as it can significantly alter the behavior of applications. You can have private methods, but I can put code that runs instead of yours, or change the parameters or the return value before or after the method is called.
To protect variables inside of classes, you can make them private, and accessible via getter and setter methods with varying levels of protection. This also applies to classes themselves; if you wanted to prevent the user from being able to instantiate a class, you could mark the class' constructor as protected to allow instantiation only within it's package.
If you wanted to hide the implementation details of a class altogether, you could declare the class as class X instead of public class X, which would hide methods from the API for standard development.
This will quickly get you the behaviour you're after, but there's an aspect of Java called reflection, which allows an executable Java program to analyze and manipulate it's own implementation; in this regard, no field or method is ever completely safe.
You can also safeguard variables by providing access to them via 'immutable' Objects; these are objects designed to forbid the caller from modifying the original source contents.
I am starting to learn about EJB, despite I know they handle the business logic, I don't understand why an EJB has to implement an interface.
I know that the interface is a list of the methods and is used by the client to access them, but what if I don't use an interface?
I know that the no-interface view exist but when should I use an interface then?
could you please explain it using a no IT example? I am taking a course about Java EE 7 and I am stuck in this part, I have read the Oracle tutorial but I've got problems understanding this.
I apologize for my wording mistakes.
thanks in advance
The reason for an interface is because you need to invoke a method in one JVM that transparently can invoke your EJB in another JVM. All the complexity of Java EE come from that it is designed to work across multiple JVMs.
This can be handled in many ways. The approach chosen here is that an interface can make this almost transparent in your code (just compare with invocation through reflection) but the object in the first JVM contains not your code, but instead code that knows how to reach the other JVM and ask it to invoke your method and return the result.
In other words, an interface allows the compiler to help you doing it right in your code, and the application server then provides the magic glue in the object called to reach your EJB.
An EJB doesn't have to implement an interface (anymore). Well, this is only true, if you haven't different VMs accessing the same EJB container. You could host your JBoss in the cloud (e.g.) and have another JEE-Server (e.g. Tomcat) at your company site (or anywhere else) and let the TomEE retrieve its EJB instances from the JBoss Application Server. Then you have to use an interface to program against, since you don't know what the implementation will be.
Since EJB 3 no-interface views are possible. You're free to use interfaces, but you shall be happy if you don't... as long as you dont need distributed EJB-services.
An interface is always a great choice, when you design a big system though. You can easily change you underlying logic if you program against the interface and not the concrete class. So if specifications change, code is much easier to maintain.
I have a library class that is a singleton and does NOT implement any interface (So I'm assuming I cannot use dynamic proxies). But, I need the same functionality as the dynamic proxy. I need to hijack the call, log some data and pass on the call to the library as is.
Is it possible to do this without having to use AspectJ or Spring AOP? (I'm not sure how to use these frameworks, but I will have to look into it if there is no other way).
You can provide your own implementation of the same class, with the same name and package, and try to put it into classpath first. The calling code with such classpath will pick the intercepting class first, and the intercepting class can call others classes of the actual package to provide its actual functionality.
Best would be to remove the overridden class from the library .jar with archive tool.
You could change the import statements in the classes that call f() so that they see a different class that implements f(). The implementation of that class would do the logging and call the real f().
Still requires some editing, but less than changing every call.
BTW: Depending on the size of the project, you may want to consider making wrappers to that "black box" anyway, if this type of requirement will be ongoing.
Like I started in my comment wrapper all the classes you implement from the external library. Then call the external library from your own classes this way you can log in the function(s) you want. If you use the same function name then you don't have to change what you call you only have to change your import(s). Most IDEs provide mass name replace so it shouldn't be too big of a burden it will be tedious however.
I don't know the meaning of using proxy in spring. what is efficient?
Proxies are used by AOP. In short:
Normally you have.
Caller --> Real object
But when, for example, you want automatic transaction management, spring puts a proxy of your real object
Caller --> Proxy --> Real object
where the proxy starts the transaction.
Here is nice article explaining both the essence of proxies and their efficiency (performance) in spring
The dynamic proxy is a feature of the JDK. It can be used to implement an interface using an invocation handler.
A dynamic proxy class (simply referred
to as a proxy class below) is a class
that implements a list of interfaces
specified at runtime when the class is
created, with behavior as described
below. A proxy interface is such an
interface that is implemented by a
proxy class. 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 dynamic proxy has some overhead. For most use cases the overhead won't be significant, though. The real problem is that the (over)use of dynamic proxies makes an application harder to understand and debug. For example a dynamic proxy will show up with mulitple lines in a stacktrace.
Dynamic proxies are often used to implement decorators. One example of this is AOP in Spring. (I don't want to go into the details of AOP and won't use AOP terminology to keep things simple). Where certain concerns are implemented in one class and used in many places. The dynamic proxies (and invocation handlers) are only the glue code (provided by Spring) to intercept the method calls. (Actually, dynamic proxies are only an implementation detail of this capability. Generating classes on the fly is another possibility to implement it.)
We can add a functionality to Java class by modifying the source/byte code or by using subclass or proxy which embeds the additional functionality and delegates the calls to underlying object.
The other answers are good, but here's how I think of it in very simple terms.
An annotation means "add hidden code for extra behavior."
The framework (or whatever knows what the annotation means) adds bytecode, Spring at runtime, AspectJ at compile time, for example.
It adds code as a proxy along with an interceptor. (A wrapper, decorator, adapter are similar and may be easier to understand than "proxy".)
When the program runs, the interceptor sends execution to the proxy which does its thing, which then may or may not send execution to the class that you coded and that it "wraps".
AOP can also use CGLIB proxies. This is used to proxy the classes instead of interfaces.