<p dir="ltr">I would sise with Atilla here, at least partially. While it's perfectly reasonable to focus on J in JDK, jdk is still a widely used platform for many languages, that are built on top of trust into respect of JVM-based languages by Java designers.</p>
<p dir="ltr">Specifically in that case, I wouldn't say that this is kind of an issue that is significant enough to discard the idea, it is still a con of this change, and, imo, must be accounted. Though for kotlin specifically, there are much greater compromises that kotlin devs are used to than final variable that may be accidentally initialized twice</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 15, 2024, 21:30 Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sun, Jul 14, 2024 at 1:19 PM Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" target="_blank" rel="noreferrer">attila.kelemen85@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I still say it's not a big enough problem to worry about. If you're "going around" the JLS with tricks, some JLS guarantees are invalidated, just like with unchecked casts, etc.</div></div></blockquote><div><br></div><div>The reason I would worry is because there are languages like Kotlin and from its own perspective it is perfectly fine to throw any exception. And someone might want to call it from Java (not realizing the possibility). I think this is worse than unchecked casts and whatnot, because it doesn't blow up in your face. You will just get an impossible value (likely 0 or similar) which would be very hard to track down if it happens. Given that you are catching the exception, you might not even get to see the stacktrace in the logs. I think this would only be an acceptable risk if the compiler would protect you from such exceptions by wrapping the checked exception into an unchecked one.</div></div></div>
</blockquote></div><div><br></div><div>Hmm.. this is starting to sound a little out of bounds. If using Kotlin creates some new danger that wasn't there before, how is that Java's problem?</div><div><br></div><div>And in any case, wouldn't you already have a similar issue in any normal try/catch scenario with respect to Java's checked exceptions?</div><div><br></div><div><span style="font-family:monospace">    obj.method();   // might call kotlin and throw IOException??<br></span></div><div><span style="font-family:monospace">    try {</span></div><div><span style="font-family:monospace">        in.read();</span></div><div><span style="font-family:monospace">    } catch (IOException e) {</span></div><div><span style="font-family:monospace">        // handle exception<br></span></div><div><span style="font-family:monospace">    }<br></span></div><div><br></div><div>-Archie</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</blockquote></div>