http://gwt-code-reviews.appspot.com/1859803/diff/2001/user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java
File
user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java
(right):
http://gwt-code-reviews.appspot.com/1859803/diff/2001/user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java#newcode216
user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java:216:
protected JavaCompiler getJavaCompiler() {
For no particular reason, I was trying to defer creating the
JavaCompiler until it's actually needed. If this code was already using
JSR330, I'd add a constructor that takes a Provider<JavaCompiler> and
handle it that way. Since it's not and I don't expect to see too many
custom ValidationTool subclasses, just adding an override method seemed
the least intrusive solution.
http://gwt-code-reviews.appspot.com/1859803/diff/6001/user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java
File
user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java
(right):
http://gwt-code-reviews.appspot.com/1859803/diff/6001/user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java#newcode212
user/src/com/google/web/bindery/requestfactory/apt/ValidationTool.java:212:
public void run(String[] args) throws IOException {
On 2012/10/24 20:56:48, tbroyer wrote:
Er, why this method?
Mostly so that I can just write:
class FancyValidationTool extends ValidationTool {
public static void main(String[] args) throws IOException {
new FancyValidationTool().run(args);
}
protected JavaCompiler getJavaCompiler() { ... }
}
I could reproduce the System.exit() logic in FancyValidationTool too,
but this way just seemed simpler (and ValidationTool already does things
like write to System.err directly). I'm fine with making main()
responsible for calling System.exit() if you find this way distasteful.
http://gwt-code-reviews.appspot.com/1859803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
