Bug 247207 - runtime (non-debug) string evaluation
Summary: runtime (non-debug) string evaluation
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.5   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-12 21:51 EDT by Florin Mateoc CLA
Modified: 2008-09-22 11:26 EDT (History)
4 users (show)

See Also:


Attachments
java source file implementing the feature (19.55 KB, patch)
2008-09-12 21:51 EDT, Florin Mateoc CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Florin Mateoc CLA 2008-09-12 21:51:56 EDT
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
Comment 1 Jerome Lanneluc CLA 2008-09-15 06:45:58 EDT
How is this different from the "org.eclipse.jdt.core.eval" evaluation support?
Comment 2 Florin Mateoc CLA 2008-09-15 11:39:49 EDT
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.
Comment 3 Jerome Lanneluc CLA 2008-09-19 06:59:17 EDT
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.
Comment 4 Florin Mateoc CLA 2008-09-19 11:11:28 EDT
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
Comment 5 Jerome Lanneluc CLA 2008-09-22 05:33:07 EDT
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.
Comment 6 Florin Mateoc CLA 2008-09-22 11:26:21 EDT
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