<div dir="ltr">I scanned this thread but haven't yet seen any references to "Programming by Contract", so I thought I'd just mention and remind everyone about it.<div><br></div><div>But first, please don't make the "totally awesome" an enemy of the "really really useful right now." A Null/Not-null operator would be very helpful all by itself and I don't think that feature needs to wait for the Best Parameter Checking System Ever.</div><div><br></div><div>My contribution example:<br><br></div><div> //With apologies to Demeter.<br> <br> //API:<br> FooType foo = obj.nested1().nested2().fooProvider().getFoo();<br><br> //CURRENTLY<br> FooType foo = null;<br> if (obj != null<br> && obj.nested1() != null<br> && obj.nested1().nested2() != null<br> && obj.nested1().nested2().fooProvider() != null) {<br> foo = obj.nested1().nested2().fooProvider().getFoo();<br> }<br><br> //WANTED <br> FooType foo = obj?.nested1()?.nested2()?.fooProvider()?.getFoo();</div><div><br></div><div>A not-null assertion is also nice to have. </div><div>...</div><div>// The underscore is here only to make the exclamation point more clear in the variable name</div><div>result = obj_!.getThing(); </div><div><br></div><div><br></div><div>Ok, now on to Program/Design by contract. This is a very useful technique. Whenever I've used it, it has always been in an ad-hoc fashion. But the "Checkers" being discussed above really seemed similar in my mind to this concept. Being able to specify your pre-conditions, post-conditions, and invariants in one place makes it easy to:</div><div>1. Discover the rules easily</div><div>2. Communicate clear intent to caller</div><div>3. Make it easier to reason about state in the called function</div><div>4. Makes the code easier to debug and maintain</div><div><br></div><div>How to implement them? Well first I feel like these Conditions could apply both to a specific argument or return value, and/or apply to the function as a whole. I.e.,</div><div><br></div><div>FooType doSomething( T1 t1, T2 t2) {...}</div><div><br></div><div>And perhaps t1 is an Enum and t2 can only take on certain values based on the value of that Enum. So individual parameters could have a Contract and/or the function could have a Contract that would be some type of implementation of a Mediator pattern. That's the high level idea. As has been discussed, Annotations are just post-it notes on Symbols that no one is required to read. So if they are not available, some other mechanism would need to be used.</div><div><br></div><div>Now, for my own method parameter verification, I used to check and throw RuntimeExceptions, as I viewed these as programming errors that should all be fixed in production code, obviating the need for the check and the exceptions in production. For code in the critical path, I would eventually remove these checks so runtime performance was not taking the hit. By the time I did this, I had robust unit tests that would ensure these kinds of errors could be caught at testing time. However, tests can't catch new bugs that have no tests for them yet. And developers new to the code (which includes me about 4 months after I have written it), could still introduce bugs by passing in unexpected data, necessitating the check-and-exception code to be reintroduced to the buggy methods.</div><div><br></div><div>I have since discovered the power of assertions, via the simple `assert` keyword. Now I have the best of both worlds. I never have to delete my argument checks, so they are always working to enforce the contract. I can enable them in development and disable them in production so they aren't a performance hit. </div><div><br></div><div>I wonder if this new Contract feature might do something similar? Maybe even, dare I say it, allow injecting asserts into actual byte code!!! (I know, I know, the Scandal!!) Then the developer has the final say on if those asserts are acted upon and in what environments it's appropriate.</div><div><br></div><div>If not by asserts then perhaps by some new mechanism.</div><div><br></div><div>What I have describe so far are really simple checks on the domain and not-nullness, etc, of method arguments. It has assumed that you can completely enumerate the valid and not valid ranges of arguments at compile time. That will not always be possible, especially for complex invariants that depend on the runtime state.</div><div><br></div><div>So I again see another dimension for these Contracts, `runtime` and `compile time`. Compile time Contracts could likely be fully implemented with the existing assert mechanism. And they could be removed from the bytecode in production environments, so there would be no performance cost. Runtime Contracts would still require checking at runtime, and could introduce a performance penalty, but I'm not sure this would be any greater than what we are already doing in robust, fault-tolerant production code. </div><div><br></div><div>And maybe Contracts are just lambdas under the hood that are passed the method arguments before the method is invoked and the developer is completely on their own on implementing the code, deciding when to use an assert or when to use check-throw. </div><div><br></div><div>And for my final trick, I think Contract programming would be very useful, and so does everyone who has replied to this thread. Perhaps useful enough to justify a new type of processor to be added to Java? One that could affect bytecode at compile time? The Contract Processor perhaps? With Annotations java got the @ operand. I hear that </div><div><font size="6">©</font></div><div>Is available and will work for free! </div><div><br></div><div>public void dial(©PhoneNumber String Number) {...}</div><div><br></div><div>- Rob</div><div><br></div><div>P.S. the © was just for dramatic effect. In a mono-spaced code font it looks terrible and would be hard to distinguish from @. But maybe there are designers that could help with that, perhaps choosing an easy-to-type special symbol in the BMP that looks like the copyright but more legible. </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Oct 16, 2025 at 1:41 AM Aaryn Tonita <<a href="mailto:atonita@proton.me">atonita@proton.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:Arial,sans-serif;font-size:14px">I somewhat feel like these side car static type analysers fail to catch on in Java because annotations are too flexible and thus poorly suited for catching type information. In comparison with python where there are many tools but there may only be a single type annotation, in Java there are many tools with multiple overlapping type annotations that can each be redundantly applied while there is only a single language level type ascribed that doesn't support restrictions without OOP ceremony. If there was a dedicated unique additional type annotation maybe tools would attempt to be more interoperable with one another but also maybe not.</div><div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div style="font-family:Arial,sans-serif;font-size:14px">Today we have tools like Checker competing with JSpecify and the tools that came before it, and JSpecify even pointing at the sad state of affairs in a stackoverflow question (on the level of null restriction) where there are many competing and poorly interoperating tools. When the interoperability story is complex, the choice is hard to make and living with the lack of restrictions seems ok (alternately one can make between simply guarding like usual or going with the OOP ceremony).</div><div style="font-family:Arial,sans-serif;font-size:14px">
<div>
</div>
<div>
</div>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div>
On Thursday, October 16th, 2025 at 2:12 AM, Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" target="_blank">archie.cobbs@gmail.com</a>> wrote:<br>
<blockquote type="cite">
<div dir="ltr"><div dir="ltr">On Wed, Oct 15, 2025 at 11:34 AM Manu Sridharan <<a href="mailto:manu@sridharan.net" rel="noreferrer nofollow noopener" target="_blank">manu@sridharan.net</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><div dir="ltr">This is all mostly possible via the Checker Framework and similar approaches. </div></div></blockquote><div><br></div><div>In the spirit of due diligence, I am attempting to implement something like "WHAT I WANT" using the checker framework. Currently I'm battling a poor progress/confusion ratio.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr">You wouldn’t need <code style="border:1px solid rgb(206,206,206);background-color:rgb(248,248,248);padding:0px 3px;border-radius:4px">@SuppressWarnings</code> annotations for validation either, due to <a href="https://checkerframework.org/manual/#type-refinement" rel="noreferrer nofollow noopener" target="_blank">type refinement</a>. And, for this type of property, where you’re essentially trying to introduce new subtypes of an existing type and then enforce type compatibility at assignments, the implementation effort to write the checker is pretty low.</div></div></blockquote><div><br></div><div>Let me know offline if you (or anyone else) is interested in helping me prototype something (I have a primordial github project).</div><div><br></div><div>Thanks,</div><div>-Archie</div><div> </div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</blockquote><br>
</div></blockquote></div>