<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Thanks for the comments - this is an interesting discussion. There are lots of angles so I'll try to focus on one or two at a time.</div><div><br></div><div><div>Ethan McCue <<a href="mailto:ethan@mccue.dev" target="_blank">ethan@mccue.dev</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As I see it, your proposal #1 is already viable</blockquote><div><br></div><div>Can you elaborate on how that would work?</div><div> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maybe let's interrogate this from the other side: Why is this not easy
to do? What friction points are essential (you do need to get a
processor and put it on paths - what else?) and which are artificial?
Clearly it's harder than a "normal library," why is that?</blockquote><div><br></div><div>Here's a very simple, concrete example of what I want. To be honest, I'm not sure whether this is just "difficult" or "impossible" today, but in some sense that doesn't matter - either way, it's too hard!</div><br><div>WHAT I HAVE: Zillions of lines of code that look roughly like this (continuing the previous <a class="gmail_plusreply" id="m_7276368030570384360gmail-plusReplyChip-4" style="font-family:monospace">@PhoneNumber</a> example):</div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"> public void dial(String pn) {</span></div><div><span style="font-family:monospace"> Preconditions.checkArgument(pn != null && pn.matches(PhoneNumber.PATTERN));</span></div><div><span style="font-family:monospace"> ... // do whatever</span></div><div><span style="font-family:monospace"> }</span></div><div><br></div><div>WHAT I WANT: To be able to instead say this:</div></div><div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"> public void dial(@PhoneNumber String number) {</span></div><div><span style="font-family:monospace"> ... // do whatever</span></div><div><span style="font-family:monospace"> }</span></div><br></div><div>AND have the following be true:</div><div><ul><li>At compile time...</li><ul><li>I get a warning or error if any code tries to invoke <span style="font-family:monospace">dial()</span> with a "plain" String parameter, or assign a plain String to a <a class="gmail_plusreply" id="m_7276368030570384360gmail-plusReplyChip-4" style="font-family:monospace">@PhoneNumber String</a></li><li>There is some well-defined, compiler-sanctioned way to validate a phone number, using custom logic I define, so I can assign it to a<span style="font-family:monospace"> @PhoneNumber String </span>without said error/warning. Even if it involves <span style="font-family:monospace">@SuppressWarnings</span>, I'll take it.</li></ul><li>At runtime...</li><ul><li>No explicit check of the<span style="font-family:monospace"> number </span>parameter is performed by the <span style="font-family:monospace">dial()</span> method (efficiency)</li><li>The<span style="font-family:monospace"> dial() </span>method is guaranteed (modulo sneaky tricks) that<span style="font-family:monospace"> number </span><span style="font-family:arial,sans-serif">is </span>always a valid phone number</li></ul></ul><div>Obviously you can replace<span style="font-family:monospace"> @PhoneNumber </span>with any other assertion. For example:<span style="font-family:monospace"> public void editProfile(@LoggedIn User user) { ... }</span></div><div><br></div><div>Is the above possible using the checker framework? I couldn't figure out how, though that may be due to my own lack of ability.</div><div><br></div><div>But even if it is possible via checker framework or otherwise, I don't see this being done in any widespread fashion, which seems like pretty strong evidence that it's too hard.</div><span class="gmail_signature_prefix"><br></span></div><div><div>Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I just want to point out that there's a sort of "syntax error" in your proposal....Java provides annotations as a means of "structured comments" on declarations and type uses, but the Java language does not, and will not, impart any semantics to programs on the basis of annotations.</blockquote><div><br></div><div>Right - it's like Java gives us sticky notes, but they are limited to just being "developer notes", and the compiler support for plugging in custom automation using those notes (annotation processors) is too limited to implement the above idea.</div><div><br></div><div>So (side note) in theory this whole idea could be redirected toward expanding compiler "plug-in" support instead of "annotation hacking".</div><div><br></div><div>But I think it's OK for certain "sticky notes" to be understood by the compiler, and have the compiler offer corresponding assistance in verifying them (which it is already doing - see below). I also agree that having annotations affect the generated bytecode ("runtime semantics") is a big step beyond that, but maybe that's not necessary in this case.</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">If you mean that the compiler actually is going to get into the act, though, then this is not an annotation-driven feature, this is a full-blown language feature and should be thought of accordingly. I know its tempting to view annos as a "shortcut" to language features, but if something has semantics, its part of the language, and sadly that means no shortcuts.</blockquote></div><br><div>I agree in principle. Unfortunately that sounds like something that would take a long time to happen.</div><div><br></div><div>Moreover, there is at least one counter-example to your claim: <a class="gmail_plusreply" id="plusReplyChip-11"><span style="font-family:monospace">@Override</span>. That</a> annotation is not just a "developer sticky note" - it triggers a compile-time error if what it asserts is not true - precisely what we want here.</div><div><br></div><div>Just curious... What was the thinking that allowed<span style="font-family:monospace"> @Override </span>to be an exception to the rule, and why would that thinking no longer apply?</div><div><br></div><div>And after all, who doesn't love<span style="font-family:monospace"> @Override </span>? :)</div><br><div dir="ltr">-Archie</div><div dir="ltr"><br></div><div dir="ltr"><div><span class="gmail_signature_prefix">-- </span><br></div><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</div>