DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42838>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42838 ------- Additional Comments From [EMAIL PROTECTED] 2007-07-09 07:16 ------- (In reply to comment #1) > one question: why? Ant already has lots of support for the existing javac > apis, > to the extent that we're actually used behind the scenes in a lot of places. > What is so compelling about the new API that we need to add a new > implementation > and the test cases to match? > > The only thing would make it compelling to me would be if non-forking javac > would stop leaking very large (multi-megabyte) static data structures. Is > there > any discussion in that in the API? Whenever we reported that problem to sun in > the past, it was always dismissed as a WONTFIX "you shouldnt be running javac > in-process". javac should no longer leak data as you describe. If it does, that would be regarded as a bug that would be fixed. JSR199 is a specific response to the demand to be able to run javac (and related tools) in process and reflects a commitment to that mode of operation. In addition, the JSR 199 API gives better OO access to the diagnostics generated by the compiler. It also provides support for reading and writing files from alternate storage media (e.g. memory, zip files, etc) through the use of the JavaFileManager. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
