17

Here is a simple example of some code that compiles using Java 6, but does not compile in Java 7. 

public class Test<T extends Test> {

  private final int _myVar;

  public Test(int myVar) {
    _myVar = myVar;
  }

  public int get(TestContainer<T> container){
    T t = container.get();
    return t._myVar;
  }

  private static class TestContainer<T extends Test> {
    private final T _test;
    private TestContainer(T test) {
      _test = test;
    }
    public T get(){
      return _test;
    }
  }
}

In Java 7, it fails to compile in the get(TestContainer<T> container) method, with the error:

error: _myVar has private access in Test

I don't understand why this no longer compiles - in my mind it should. The variable t is of type T, which must extend Test. It's trying to access the field _myVar of a instance of Test from within the class Test.

Indeed, if I change the method get(TestContainer<T> container) to the following, it compiles (with no warnings):

public int get(TestContainer<T> container){
  Test t = container.get();
  return t._myVar;
}
  • Why does this no longer compile?
  • Was this a bug in Java 6? If so why?
  • Is this a bug in Java 7?

I've had a google and searched in the Oracle bug database, but haven't found anything on this...

amaidment
  • 6,942
  • 5
  • 52
  • 88
  • 5
    This was a bug in Java 6: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7022052 – pingw33n May 28 '12 at 10:47
  • @pingw33n, you should post that as an answer. – Louis Wasserman May 28 '12 at 12:09
  • @pingw33n, and then I can accept it... although if anyone who has a better understanding of the JLS can explain the 'Evaluation' section of the bug report, I'd appreciate that too. – amaidment May 29 '12 at 07:27
  • I am surprised that this worked in 1.6 until I saw the bugreport. Why you whould have access to a private field of an instance of a child class? – brimborium May 29 '12 at 12:25

3 Answers3

10

§4.9 ... Then the intersection type has the same members as a class type (§8) with an empty body, direct superclass Ck and direct superinterfaces T1', ..., Tn', declared in the same package in which the intersection type appears.

From my understanding of that JLS part, your case with a type variable <T extends Test> creates the following intersection:

package <the same as of Test>;

class I extends Test {}

Therefore when you access members of the type T you actually access members of the intersection type I. Since private members are never inherited by subtypes accessing such member fails with compile-error. On the other hand access to package-private (default) and protected members is allowed by the fact the intersection is

... declared in the same package in which the intersection type appears.

pingw33n
  • 12,292
  • 2
  • 37
  • 38
0

See @pingw33n's comment for the answer, but the way to fix this is to remove the generic parameters on the nested class. Unless you have a use case where the inner and outer T's can be different, they are redundant. All they are doing is causing this grief.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Are you suggesting making it simply: `private static class TestContainer`? Since the inner class static, you can't (in the terse words of the compiler) *make a static reference to non-static type T*. – Greg Kopff May 29 '12 at 06:56
  • I have a use case - the equivalent of TestContainer is actually a separate class entirely - but this is just an SSCCE to demonstrate the compiler issue that I was facing. – amaidment May 29 '12 at 07:25
0

A workaround for this is to cast the generic instance to the concrete supertype that declares the private field, e.g.

public int get(TestContainer<T> container){
  T t = container.get();
  return ((Test) t)._myVar;
}
David Moles
  • 48,006
  • 27
  • 136
  • 235