How to compile code calling unexpected classes to an older release?

joe darcy joe.darcy at
Fri Oct 28 22:13:13 UTC 2016

On 10/28/2016 11:26 AM, Jonathan Gibbons wrote:
> Keimpe,
> If you're compiling against internal JDK classes, you should be using 
> the rt.jar from the appropriate release.
> -- Jon
> On 10/28/16 10:29 AM, Keimpe Bronkhorst wrote:
>> Joe,
>> I don't understand this, doesn't this make "-release 8" useless for 
>> any code base that uses an internal JDK API, which is likely most 
>> production code bases. For instance, the Windows PLAF classes are 
>> often used:
>> import;
>> class t1 { public static void main(String[] args) {  } }
>> this will compile fine with either:
>> <jdk8_path>/javac
>> <jdk9_path>/javac --add-exports 
>> java.desktop/
>> but not with either of:
>> <jdk9_path>/javac --release 8
>> <jdk9_path>/javac --release 8 --add-exports 
>> java.desktop/

Some additional details on --release from Jan that I used in a JavaOne talk:

The APIs covered by --release are Java SE APIs along with 
@Exported(true) APIs, that is, the APIs in namespaces like jdk.* and 
com.sun.* that are not part of SE are are part of the exported API of 
the JDK. As of JDK 8, such API are marked with a @Exported(true) 
annotation. The compiler API in com.sun.soure.* is a notable example of 
an API in this category.

The types in java/awt/peer and java/awt/dnd/peer are included, but a few 
classes that are exported (or are in exported) packages are not part of 
the --release date as they are platform-specific. Some of these are 
package private (like java/io/UnixFileSystem), but there are a handful 
of classes that aren't part of the data and are @Exported(true), like 



More information about the compiler-dev mailing list