<div dir="auto">Well, that's valid. However, kotlin design choice to step off from JLS in checked exceptions handling (their absence, more specifically) has its consequences, both positive and negative, and potential incompatibilities with java code in what requirements compiler imposes to final variables in context of try/catch block is one of those. <div dir="auto"><br></div><div dir="auto">While, as I said previously, we have to respect other JVM languages, if they want both bytecode compatibility with Java and step off from JLS at the same time, it has its cost. We should not break this compatibility wherever, no matter what the price is, just because we can, but if decision to change JLS brings significant value to Java itself, we certainly should do it, and it's other language teams work to bear with outcome of their decisions.<div dir="auto"><br></div><div dir="auto">While we certainly should write this issue in "cons" column, I would not mark it as crucial as long as it does not break compatibility of Java bytecode with itself. It's J in the JDK after all.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 15, 2024, 21:52 Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@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">Olexandr Rotan <<a href="mailto:rotanolexandr842@gmail.com" target="_blank" rel="noreferrer">rotanolexandr842@gmail.com</a>> ezt írta (időpont: 2024. júl. 15., H, 20:49):<br></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">
<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></blockquote><div>Actually the main concern here is not that a variable is initialized twice (that would be whatever in my opinion). The main issue is that you might be able to observe a value of a variable that should be impossible. <br></div></div></div>
</blockquote></div>