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

[joe darcy]

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 com.sun.java.swing.plaf.windows.WindowsComboBoxUI;
>> class t1 { public static void main(String[] args) {  } }
>>
>> this will compile fine with either:
>> <jdk8_path>/javac t1.java
>> <jdk9_path>/javac --add-exports 
>> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED t1.java
>>
>> but not with either of:
>> <jdk9_path>/javac --release 8 t1.java
>> <jdk9_path>/javac --release 8 --add-exports 
>> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED t1.java


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 
com/sun/security/auth/module/UnixSystem.

HTH,

-Joe