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.
Ethan McCue <[email protected]> wrote: > As I see it, your proposal #1 is already viable Can you elaborate on how that would work? > 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? 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! WHAT I HAVE: Zillions of lines of code that look roughly like this (continuing the previous @PhoneNumber example): public void dial(String pn) { Preconditions.checkArgument(pn != null && pn.matches(PhoneNumber.PATTERN)); ... // do whatever } WHAT I WANT: To be able to instead say this: public void dial(@PhoneNumber String number) { ... // do whatever } AND have the following be true: - At compile time... - I get a warning or error if any code tries to invoke dial() with a "plain" String parameter, or assign a plain String to a @PhoneNumber String - 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 @PhoneNumber String without said error/warning. Even if it involves @SuppressWarnings, I'll take it. - At runtime... - No explicit check of the number parameter is performed by the dial() method (efficiency) - The dial() method is guaranteed (modulo sneaky tricks) that number is always a valid phone number Obviously you can replace @PhoneNumber with any other assertion. For example: public void editProfile(@LoggedIn User user) { ... } 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. 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. Brian Goetz <[email protected]> wrote: > 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. 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. So (side note) in theory this whole idea could be redirected toward expanding compiler "plug-in" support instead of "annotation hacking". 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. 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. I agree in principle. Unfortunately that sounds like something that would take a long time to happen. Moreover, there is at least one counter-example to your claim: @Override. That 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. Just curious... What was the thinking that allowed @Override to be an exception to the rule, and why would that thinking no longer apply? And after all, who doesn't love @Override ? :) -Archie -- Archie L. Cobbs
