<div dir="ltr"><div dir="ltr">On Tue, Nov 28, 2023 at 6:16 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<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">> In light of this, I would like to revisit this issue, 22 years later:<br>[...]<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is a JDK 1.1 era mistake. It would a source incompatible change to <br>
"remove" the constants. It would require corpus searches to gauge the <br>
impact. I think the question is whether it's worth the disruption, is <br>
your motivation to cleanup this area or something stronger?<br></blockquote><div><br></div><div>Alan, Lance</div><div><br></div><div>Yes, removing anything always incurs a cost. There is the cost for the OpenJDK team to assess, plan, implement and communicate the change. This is a fixed, one time, implementation and review cost for a few of us to take on.</div><div><br></div><div>Then there is also a cost paid by any project recompiling source files referencing these constants and discovering that they have been removed. Each such project will experience a fixed, one time cost to replace references with their own constants. This replacement should be relatively straightforward, given that values are readily available in Java API docs [1]. A corpus search may help us assess the magnitude of this cost. We can reduce (or at least ease) this cost by deprecating the constants for a few releases first, giving projects more time to detect and react to a forthcoming removal.</div><div><br></div><div>But keeping this "peculiarity" afloat does not come for free either. This cost is perhaps harder to assess, because it is a small cost potentially affecting many people. There are millions of Java developers out there. A good chunk of them will through their career eventually need to study the APIs of ZipFile, ZipEntry, ZipInputStream or ZipOutputStream, either by reading Javadocs, or by using code completion in their IDE. Most of them will stumble upon these constants. Some will simply scroll past them, finding what they looked for. Others will stop, wonder how these constants are supposed to be used, what part of the API allows them to be used. Most will soon think "it's probably there for a reason", and continue their work. But some will be curious, search for an explanation, ask on forums, study the source code, perhaps stumble upon JDK-4512189.</div><div><br></div><div>It's hard to say whether the cumulative cost over years of all these small distractions is larger than the fixed, one-time cost of the removal. My gut feeling says yes.</div><div><br></div><div>In any case, could it perhaps be worth at least deprecating these constants? This would signal to API readers that they were a mistake and should not be given focus. And it would give a compile warning to projects accidentally referencing the constants.             </div><div><br></div><div>Then we can spend a few releases deciding whether a removal is warranted.</div><div><br></div><div>Eirik.</div><div><br></div><div>[1]</div></div></div>