RFR: JDK-8207224: Javac compiles source code despite illegal use of unchecked conversions

[joe darcy]

Hello,

We don't have quantitatively limits per se, but try to be guided by the 
numbers in a reasonable way. For example, we used a quantitative 
approach to help design diamond and subsequent language features.

At some level, with nearly any javac change there is a risk of some 
source incompatibility. That said, we don't want to bloat either the 
release notes documenting mostly innocuous changes or push us bug fixes 
to future source levels. Of course It is more concerning if the changes 
prevents code that previously compiled from compiling.

For this change, I think it is more reasonable to get it in at the start 
of a release cycle rather than toward rampdown to allow more time for 
adjustment if needed.

HTH,

-Joe

On 12/3/2018 4:29 PM, Liam Miller-Cushon wrote:
> There was a mention of crisper data in the CSR: for the corpus I 
> looked at, the fix affected one file per 202,000.
>
> On Mon, Dec 3, 2018 at 10:50 AM joe darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Since it sounds like there is nontrivial source compatibility
>     impact with this change, please file a CSR for it.
>
> Out of curiosity, what's the bar for whether a source incompatibility 
> is nontrivial-enough to warrant a CSR, or putting behind a flag?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181218/6be5f20e/attachment.html>