9

What are the potential issues I need to look out for when using reflection. I am very confused in reflection, Why java provide this type of functionality to access private data member.

Private : Like I'd think, only the class in which it is declared can see it.

Then Why it is possible to access private things in other class? this terminology (reflection) completely overflow my concept of private(Access Specifier) properties in java.

I visited many links about this topics but not given complete explanation about this topics. eg:

package example;

import java.lang.reflect.Method;

class A{
    private void privateMethod(){
        System.out.println("hello privateMethod()");
    }
}
class B{
    public static void main(String[] args) throws Exception {
        A d = new A();
        Method m = A.class.getDeclaredMethod("privateMethod");       
        m.setAccessible(true);
        m.invoke(d);
    }
}

So please explain scenario about this approach in depth? I need advantage and disadvantage of private methods accessibility in other class?

Kara
  • 6,115
  • 16
  • 50
  • 57
Avanish Singh
  • 767
  • 2
  • 8
  • 32
  • 11
    http://stackoverflow.com/questions/1239581/why-is-it-allowed-to-access-java-private-fields-via-reflection – peter.petrov Oct 16 '15 at 07:52
  • 1
    Most regular projects shouldn't need any reflection, since if you do you simply need to re-think about your architecture (there are exceptions of course). One place where I regularly use reflection though is in UnitTests. You can simply try multiple scenarios by changing a private field using reflection in the UnitTests. For example a boolean. Let's say that you have a boolean-setting and you want to test both scenarios in a UnitTest. The default in your project is false, so you first test that. And then you use reflection to put it (temporary) on true and test the other scenario. – Kevin Cruijssen Oct 16 '15 at 07:54
  • can any one explain with an example? because it will very clear about my concept. – Avanish Singh Oct 16 '15 at 08:01
  • 6
    You tagged your question with "security". I think that's where your misunderstanding is. Access modifiers are not meant to be a security mechanism. They're meant to be an OO design tool. Accessing private fields through reflection is useful when you want to provide properly encapsulated code to "regular" clients of your code, but still want to have frameworks (like JPA, dependency injection, etc.) populate the fields for you. – JB Nizet Oct 21 '15 at 05:59
  • `private`, `protected` and `public` are limited means to build a software architecture in an ordered way. For instance `public` is used to often due to usage of interfaces, and public cannot be restricted in a child class. So it is more a language style tool. The module system of java 9 will at least provide real barriers (via class loaders). You might use proxy classes, the OSGi module system, AOP. – Joop Eggen Nov 03 '15 at 14:11
  • @JBNizet If you are running untrusted code, this can be a security issue. An example is in an applet context. It could also occur in a situation where you are hosting java code. – JimmyJames Apr 04 '16 at 19:34
  • 1
    @JimmyJames I'm not saying that security isn't an issue. I'm saying that access modifiers are not an answer to security issues. They're not meant to provide security. They're meant to provide ancapsulation. They're a design tool. – JB Nizet Apr 04 '16 at 19:37
  • @JBNizet I get what you are saying. I'm telling you that saying this isn't a security issue is not strictly correct. See here: http://www.cs.ait.ac.th/~on/O/oreilly/java-ent/security/ch02_01.htm under "Java Language Security Constructs" for a discussion of access modifiers. If you aren't building applets (I don't) or hosting untrusted code on your server (I don't but google does) then I agree, this isn't especially relevant to security. – JimmyJames Apr 04 '16 at 20:25
  • @JimmyJames again, I never said "this isn't a security issue". I said "Access modifiers are not meant to be a security mechanism". Let me make a car analogy. Someone asks: "I've been walking on the white line on the middle of the road for years, but I just realized many people are run over by cars and trucks by doing that. Why? Cars are not supposed to drive on that line". My answer is: "the white line has never been meant as a place to let people walk safely. You shouldn't use the white line to walk safely. There are sidewalks for that. The white line is useful, but not to walk safely." – JB Nizet Apr 04 '16 at 20:37
  • @JBNizet Did you look at the link I posted? If you mark a member as private in a secured JVM, Un-trusted code cannot access it (in theory, anyway.) If you mark it as public, un-trusted code can access it, regardless of the JVM security settings. How is `private` not a security mechanism in this context? If you do not mark sensitive data or methods as private (or other restricted access) in, say, an applet, any code may access them. My main point is saying that the security flag is relevant here. – JimmyJames Apr 04 '16 at 21:00
  • OK. Now I understand your point. – JB Nizet Apr 04 '16 at 21:39

2 Answers2

1

All "Private" and the other forms of declaration are, are flags for the development tool so that it knows how you intend to use the field or method in question. This is so the development tool can gives warnings or errors to the developer when they use these classes/fields/methods in a way they were not intended.

Reflection is a tool which lets the developer ignore or circumvent these flags which indicates that you are using the class/field/method in a way it was never intended. So in general reflection shows bad architecture.

So there are no "advantages or disadvantages" to declaring something as private or public or static; they're simply tools to help keep your code clean and compartmentalised by only allowing developers to access/use your classes/fields/methods in particular ways.

Dynisious
  • 46
  • 5
  • 3
    This is incorrect. The JVM will enforce accessibility (disabling reflective workarounds) when a security manager is present. To say that this is "just" a compile-time hint is wrong; its just that the security manager is not enabled by default (and building an app in the presence of a SM is harder). These reflective features are used by some very useful frameworks, such as serialization-like frameworks, distributed object caches, persistence frameworks, and mocking frameworks. – Brian Goetz Apr 04 '16 at 21:21
1

In most situations, access modifiers are meant to help keep parts of your code that you don't want people binding to out of view. The ability to access private methods using reflection can useful from a tooling perspective. Java has a security mechanism that allows this feature to be disabled. This site has some information about the java security model related to reflection (bottom of the page.)

This really only matters in situations where your code will be executing with un-trusted code. If other developers have access to your code or have your libraries, there's nothing you can do to stop them from running the code without a security manager or changing the modifiers, for that matter. This is only effective in a controlled environment.

JimmyJames
  • 1,356
  • 1
  • 12
  • 24