A,
This is an area I have been contemplating also for some time.
I think the least code impact mechanism would be to annotate a method
parameter as being a particular stringly type and have the compiler or
annotation processor syntax check any literals that are passed to those
methods as that parameter. The problem with doing this as an annotation
processor is that the java.lang.model doesn't model the content of
methods - so it would either require implementation in the compiler (ie
become a full blown language feature), or else an annotation processor
hack that goes down into the AST for the compiler it is running in
(possible to do, just not universal guaranteed). There is also the
problem that the methods to be annotated are mostly in the JDK classes
(unless you have your own stringly types, but commonly they are the ones
you identified.
Alternatively your approach of annotating a final static field is
workable, but the coder must remember to apply the annotation, and to
put the literal in a field rather than using it directly. I suspect I
wouldn't use that unless I really wasn't sure about my regex (say)
syntax. And If I wasn't sure, I could validate it manually somehow when
I coded it. A checker (in-compiler) like this is going to be most
valuable when you get it for free.
Also note that the apt tool has been removed from JDK8 so if you haven't
done so, you should migrate apt based tools to the annotation processing
API (javax.annotation.processing and java.lang.model.* packages).
Bruce
On 20/02/2013 1:14 p.m., A McDowell wrote:
Caveat: what follows assumes that you find value in detecting syntax
errors in the pre-"unit test" phase of development. That isn't to say
that the most appropriate place to solve these issues isn't during
unit testing, but I thought I'd throw the problem out to the group. If
this is old ground & my search skills have failed me, feel free to
point me at articles/posts/code.
I've been thinking about how to validate the stringly-typed[1] things
I use (to greater or lesser degrees.)
Within Java SE:
- java.util.regex.Pattern
- java.util.Formatter
- java.text.MessageFormat
- javax.xml.XPath
- java.net.URI
In the case where inputs to these types are static string constants
their syntax can be validated at compile time via annotation
processors. Expand into enterprise containers and you start
encountering things like EL syntax.
I've written some proof-of-concept code[2] that validates against the
JRE implementation but such tests are unlikely to be consistent across
JRE versions/implementations.
What should they be validating against? Grammars? How do you specify
the grammar given SPIs/JRE implementation bugs/etc? Runtime
implementation? How do you handle things like XPath functions?
I don't expect there'll be a catch-all answer; every DSL has different
constraints; every project has its own needs. I'm just curious as to
how other people are approaching these problems.
[1] http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html
[2]
http://illegalargumentexception.blogspot.co.uk/2013/01/java-validating-regular-expression.html
--
You received this message because you are subscribed to the Google
Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/javaposse?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/javaposse?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
