RFR: JDK-8207224: Javac compiles source code despite illegal use of unchecked conversions
joe darcy
joe.darcy at oracle.com
Tue Dec 18 20:27:46 UTC 2018
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>
More information about the compiler-dev
mailing list