Community
Participate
Working Groups
Some users want to call the batch compiler from their code but without involving the eclipse platform. They have used internal method org.eclipse.jdt.internal.compiler.batch.Main#compile(String commandLine, PrintWriter outWriter, PrintWriter errWriter), but this is not viable since this is not API. JSR-199 is not applicable for 1.5 level, while there is a need for 1.5 and maybe even 1.4.2. There is a need for progress reporting. Hence the requirement: an API that would have basically the same capabilities as the non-API method above, plus a progress reporting ability that would not depend on any Eclipse platform plugin (aka only depend on ecj.jar), made available for 1.4.2 and above.
Progress reporting would also need to allow cancellation, which would be good to introduce in compiler, so it would improve cancellation for the Java builder or other tools which are currently relying on compiler I/O to force cancellation (throwing abort compilation).
Kent, since Maxime is too busy on other front, please take care of this bug (this is a must have for M6). Please talk to Philippe or myself if you need clarification.
In TPTP (bug 187723), internal method org.eclipse.jdt.internal.compiler.batch.Main.compile(String) is called for the same purpose. TPTP needs an API that would have basically the same capabilities as the non-API. This is part of an effort to remove all internal reference in TPTP. Please let me know if you need detail about the usage of the API in TPTP.
Correction: the TPTP bug number should be bug 126584. Not bug 187723.
Created attachment 92829 [details] Proposed API, implementation and tests
Cosmetical suggestion: what about CompilerProgress --> CompilationProgress ?
Created attachment 92871 [details] Same patch with CompilerProgress renamed to CompilationProgress
I looked at the compiler API and it is taking in a string command line argument. Does this mean that we need to manually add double-quotes for files whose paths have spaces? Wouldn't it be better if Eclipse could handle this for adopters and adopters be allowed to pass in an array of arguments instead?
I have ported our code to use the new API and it looks OK to me. I've also tested progress monitoring and cancelation. The only thing that looks a bit confusing is that there apparently is no distinction between a cancelation and a compile error, the API returns in both cases false. Regarding comment #8, indeed I had to quote source file paths that were containing spaces.
I tried migrate my code to the new API and it looks ok to me. However I agree with Lu that it's better if the API handle whitespace within path.
(In reply to comment #9) > I have ported our code to use the new API and it looks OK to me. I've also > tested progress monitoring and cancelation. The only thing that looks a bit > confusing is that there apparently is no distinction between a cancelation and > a compile error, the API returns in both cases false. To distinguish between cancelation and a compile error, the client can still ask the compilation progress if it was canceled: CompilationProgress#isCanceled() > Regarding comment #8, indeed I had to quote source file paths that were > containing spaces. I will add a new method that takes a String array to avoid this.
Re: comment #11 , you are right, the progress monitor can be queried to find out whether the task has been canceled. An additional method taking an array of strings would be useful for sure, it would make the API more flexible. Thanks.
Created attachment 93047 [details] Version that takes a String[] as command line arguments
API, implementation and tests released for 3.4M6
Verified for 3.4M6 using build I20080324-1300.
*** Bug 185118 has been marked as a duplicate of this bug. ***
