yuqigong / sfntly

Automatically exported from code.google.com/p/sfntly
0 stars 0 forks source link

JDK7 Compile Issues #26

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Compiling with JDK7 results in errors.

$ ant
Buildfile: build.xml

compile:
    [mkdir] Created dir: /home/xxx/src/sfntly/java/build/classes
    [javac] Compiling 104 source files to /home/xxx/src/sfntly/java/build/classes
    [javac] /home/xxx/src/sfntly/java/src/com/google/typography/font/sfntly/table/Table.java:169: error: header has private access in Table
    [javac]         table.header = header;
    [javac]              ^
    [javac] 1 error

Original issue reported on code.google.com by stua...@google.com on 6 Nov 2012 at 9:31

GoogleCodeExporter commented 9 years ago

Original comment by stua...@google.com on 6 Nov 2012 at 9:31

GoogleCodeExporter commented 9 years ago
Issue is because of a change in the javac tool between Java 6 and 7.

http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#behavior
al

Area: Tools
Synopsis: Compiler No Longer Allows Access to Private Members of Type Variables
Description: In JDK 5.0 and JDK 6, javac erroneously allowed access to private 
members of type-variables. This is wrong, as the JLS, Java SE 7 Edition, 
section 4.4, states that the members of a type-variable are the members of an 
intersection types whose components are the type-variable bounds (intersection 
types are defined in section 4.9) - and intersection types do not inherit 
private members from their components. As a result, the following program 
should get a compilation error:
class A {
   private int val = 42;
}

class Test<X extends A> {
    void test(X x) {
    int i = x.val; //error in JDK 7
    }
}
The above program compiles in JDK 6. Note that accepting this program is 
inherently unsound; there is no guarantee that X will be instantiated to a type 
that inherits val. For instance, if we called test() on an instance whose type 
is Test<B>, where B is a subclass of A, val should not be accessible there. 
Since javac cannot guarantee the well-formedness of this program for all 
possible instantiations of X this program must be rejected.
Nature of Incompatibility: behavioral and source
RFE: 6246814

Original comment by stua...@google.com on 17 Jan 2013 at 7:45

GoogleCodeExporter commented 9 years ago
Fixed with r149

Original comment by stua...@google.com on 17 Jan 2013 at 7:47