Community
Participate
Working Groups
Created attachment 112477 [details] java source file implementing the feature This should be usable by embedding the compiler (just the ecj package) within the user application. The code snippet to be evaluated can be just an expression or it can end with an expression, which will provide the result of the evaluation. The API should also take as a parameter a runtime object that can be used as the receiver "this" in the code snippet. The API should provide access to problem reporting (in my implementation I interleave the caret diagnostics with the original source to give feedback to the user). I have implemented such a feature, which I am attaching here, heavily commented. Even if it is not used as-is, it should at least provide a better idea for the requirements. If you can provide feedback for better ways of doing it, or improving it, that would also be highly appreciated
How is this different from the "org.eclipse.jdt.core.eval" evaluation support?
Perhaps it is not, I confess to not have noticed it. Thank you for pointing it out. I had started to look at how debug was doing it and it looked like it only worked through jdi, not collocated. Anyway, even if it does work collocated, I don't know how self-contained it is - it is not part of the ecj package, which is distributed separately and thus easily embeddable. But if at least the plugin org.eclipse.jdt.core is self-contained, it's probably not a big deal.
In theory, the code in "/org.eclipse.jdt.core/eval" (ie. the implementation of "org.eclipse.jdt.core.eval") depends only on the compiler. So it should be possible to package it with ecj.
Not quite, it also depends on IJavaProject (I believe this is the root of the problem, since not every consumer of this code has to be an IDE), which in turns brings in a ton of unrelated stuff
The only reference to IJavaProject that I found was in code completion method org.eclipse.jdt.internal.eval.EvaluationContext.complete(char[], int, SearchableEnvironment, CompletionRequestor, Map, IJavaProject, WorkingCopyOwner) I believe this could be moved out of the 'eval' source folder (in the 'model' source folder). There might be other small code moves like this one that must be done before declaring success, but I still believe that we should try to reuse the existing support instead of rewriting a new one.
I agree that reusing the existing support is the way to go. I just hope that we would also get, in addition to the bare bones support, some glue code offering a simple API for this relatively straightforward use case