Summary
-------

During Java 8 development, the warnings for use of Sun API elements (e.g. `com.sun.misc.Unsafe`) were accidentally promoted to the status of *mandatory warnings*.

Problem
-------

Java 8 brought many changes to the Java compiler. One such change is deferred attribution -- the ability to type check an expression and later ignore the result of such attribution. Deferred attribution was a key to implement support for lambda expressions and method references.

Due to the way deferred attribution works, it is crucial that all javac diagnostics are reported in an uniform fashion, typically by calling `Log::report`. One class of warnings, namely warnings for use of Sun API element, was reported through a different method -- namely `Log::strictWarning`. This method did *not* call `Log::report`, and caused issues with deferred attribution.

To address the [issue](https://bugs.openjdk.org/browse/JDK-7148622), at the time it was decided to use `Log::mandatoryWarning` to report such warnings instead. However, this change had some adverse effects:

 * the warning could now be omitted in case the compiler generates more than 100 warnings
 * more importantly, the warning kind, which can be [seen](https://download.java.net/java/early_access/jdk25/docs/api/java.compiler/javax/tools/Diagnostic.Kind.html) using the compiler API, changes from `WARNING` to `MANDATORY_WARNING`. This is undesirable, as such warnings, while important, are not mandated by the JLS.

Solution
--------

The solution is to change the compiler to emit a non-mandatory warning, but one that cannot be suppressed or disabled -- similar to what happened prior to Java 8. Recent [changes](https://bugs.openjdk.org/browse/JDK-8350514) to the warning logging infrastructure have made this task easier to implement.

For developers, the main change is that, when using the compiler API, they will now see all Sun API warnings reported with the kind `WARNING` instead of `MANDATORY_WARNING`.

As before this change, Sun API warnings cannot be disabled, using either `-nowarn` or `-Xlint:none`. In other words, when trying to compile the following example:

```
//Test.java
import sun.misc.Unsafe;

class Test { } 
```

The following warning will always be generated (regardless of whether `-nowarn` or `-Xlint:none`):

```
Test.java:1: warning: Unsafe is internal proprietary API and may be removed in a future release
```

There is, however, a rather small difference, in that the above warning will also be generated even if javac has already emitted the maximum number of warnings (default is set to 100, but can be changed with `-Xmaxwarns <number>`, where `number` must be > 0). So, if we tweaked the example above as follows:

```
// Test2.java
import java.util.List;

class Test { 
   List<String> ls = (List)null;
   sun.misc.Unsafe U = null;
}
```

When compiled with `-Xlint:unchecked -Xmaxwarns 1`, javac used to display only *one* warning:

```
Test2.java:4: warning: [unchecked] unchecked conversion
   List<String> ls = (List)null;
                     ^
  required: List<String>
  found:    List
1 warning
only showing the first 1 warnings, of 2 total; use -Xmaxwarns if you would like to see more
```

With this change, two warnings will be displayed instead (effectively, Sun API warnings are not subject to `maxwarns`):

```
Test2.java:4: warning: [unchecked] unchecked conversion
   List<String> ls = (List)null;
                     ^
  required: List<String>
  found:    List
Test2.java:5: warning: Unsafe is internal proprietary API and may be removed in a future release
   sun.misc.Unsafe U = null;
           ^
2 warnings
```

(this restores the behavior we had for these warnings prior to Java 8).