Setting private fields from Parent class.

Question

Hi all, I have what seems to be a weird situation to me.
Basically I have two classes:
import java.lang.reflect.Field;
public class Parent {
     protected void ensureDefaults() {
          Field[] declaredFields = getClass().getDeclaredFields();
          for (Field field : declaredFields) {
               Object fieldValue = getDefaultValueForType(field.getType());
               try {
                    System.out.println("defaulting field - name: " + field.getName() + " | this: " + this);
                    field.set(this, fieldValue);
               } catch (Exception e) {
                    e.printStackTrace();
     private Object getDefaultValueForType(Class<?> type) {
          Object defaultValue = null;
          if (type.isAssignableFrom(String.class)) {
               defaultValue = "default";
          } else if (type.isAssignableFrom(int.class)) {
               defaultValue = -100;
          return defaultValue;
public class Child extends Parent {
     private String name;
     private int age;
     public Child() {
          ensureDefaults();
     public String getName() {
          return name;
     public void setName(String name) {
          this.name = name;
     public int getAge() {
          return age;
     public void setAge(int age) {
          this.age = age;
// Test Case
import junit.framework.TestCase;
public class ChildTest extends TestCase {
     public void testEnsureDefaults() {
          Child child = new Child();
          assertEquals("default", child.getName());
          assertEquals(-100, child.getAge());
}The odd thing to me is that the output looks like:
defaulting field - name: name | this: Child@7431b9
java.lang.IllegalAccessException: Class Parent can not access a member of class Child with modifiers "private"
... more exception ...
defaulting field - name: age | this: Child@7431b9
java.lang.IllegalAccessException: Class Parent can not access a member of class Child with modifiers "private"
... more exception ...
As you can see, it doesn't like me setting (or getting for that matter - tried that) these fields because they're private. However, if you look it's saying that "this" is a Child, so shouldn't those fields be accessible? Shouldn't ensureDefaults be executed as if it was being called by the Child instance?
Obviously, I can try to use the accessor methods, but that means creating strings for method names, and then looking for the methods. I'd like to avoid this and it seems to me this should work, no?
Another odd thing is that if I change the fields in Child to protected, it works fine.
Also, I'm not sure if this is important (I don't know enough about security managers to know if they're different platform to platform, version to version), I'm on a Mac OSX 10.4.11 and:
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
Any help with this would be greatly appreciated.
Thanks,
Eric

Answer 1

jschell wrote:
As you can see, it doesn't like me setting (or getting for that matter - tried that) these fields because they're private.Myself I don't like it because it suggests a design problem which is associated with understanding that although a child is a parent that doesn't mean that a parent is a child.
I understand that, but I don't see how this actually breaks that. The Child is executing a method that is passed down to it from it's Parent, but it's executing it as itself - by that I mean it's not looking at anything that it can't already look at, or at least I thought it was.
Shouldn't ensureDefaults be executed as if it was being called by the Child instance?No.Ok, I thought it was. Can you please explain this a bit more, I want to understand it.
>
Another odd thing is that if I change the fields in Child to protected, it works fine.If you messed with reflection some more you could get to to work even with private. How exactly? I really don't want to bypass any security measures (by settings accessible or using a different security manager, or anything like that). As I mentioned in my last post, what I want to do really is nothing more than a nice way to have a generic toString or hashCode method, if it's not possible to do it nicely - within java's default constraints, I'd rather not.
>
However in general the idiom would still be wrong.I'm moving more towards using beans anyway, so I plan on just calling accessor methods which corrects the "wrong idiom" right?
Thanks for all the help,
Eric