The JSR 199 EG has a number of open issues:
 
* Options, javax.tools.JavaCompilerTool.setOption and
  setExtendedOption are not appropriate.  They should
  be replaced by a java.util.Map like structure.
 
* It is currently not clear how to change the classpath
  and other paths for the built-in/default file manager.
  This needs to be resolved.
 
* Members of the EG has expressed concerns that
  javax.tools.JavaFileObject is too file-system specific.
  This is not the intent and must be resolved.
From 6324451:

Description of both methods JavaCompilerTool.run() contains superfluous statement: By convention a tool returns 0 for success and nonzero for errors. In fact both methods dosn't return int value. So the statement above misleads.

2005-09-15 17:59:03 IST ###@###.###
From 6380018:
Experience with the initial implementation of JSR 269 revealed
various impedence mismatches or missing functionality in JSR 199.
JavaFileObject.getCharContent takes a boolean saying whether or not
encoding errors should be reported.  However, there is no way for
the method to report such errors.
Should JavaFileManager.list return Iterable<? extends JavaFileObject>?
From 6358959:

javax.tools.JavaCompilerTool.run(Writer, JavaFileObject) is very confusing. 
Since run method will retun CompilationTask, to compile again it requires one more run method of CompilationTask, like javax.tools.JavaCompilerTool.run(Writer, JavaFileObject).run().

2005-12-05 05:21:28 PST ###@###.###