Presentation is loading. Please wait.

Presentation is loading. Please wait.

Fluid Eclipse Summer Work Issues, Lessons Learned, Way Ahead.

Similar presentations


Presentation on theme: "Fluid Eclipse Summer Work Issues, Lessons Learned, Way Ahead."— Presentation transcript:

1 Fluid Eclipse Summer Work Issues, Lessons Learned, Way Ahead

2 Status Eclipse parser and binder integrated into Fluid infrastructure Eclipse parser and binder integrated into Fluid infrastructure –Eclipse “hidden” via AST adapter and binder “glue” Using Eclipse, Fluid is now able to parse and bind complete Java 1.4 syntax Using Eclipse, Fluid is now able to parse and bind complete Java 1.4 syntax –assert, type statements, qualified super, nested types Effects analysis demo (mostly) working Effects analysis demo (mostly) working Lots of issues remain unsolved, but we find the Eclipse can integrate with Fluid as “envisioned” Lots of issues remain unsolved, but we find the Eclipse can integrate with Fluid as “envisioned”

3 Today’s top limitations Eclipse AST to Fluid IR “one-way” Eclipse AST to Fluid IR “one-way” Fluid IR (of Java AST) “un-versioned” Fluid IR (of Java AST) “un-versioned” –Late loading of IR and a plethora of Eclipse threads caused version-oriented problems – needs solving! Effects demo still using it’s Swing interface Effects demo still using it’s Swing interface –No time to redo UI, new UI design needed anyhow To avoid a “spider” of Eclipse dependencies in the Fluid code base we confined code into the “fluid.eclipse” package (and sub-packages) To avoid a “spider” of Eclipse dependencies in the Fluid code base we confined code into the “fluid.eclipse” package (and sub-packages) –Doesn’t break build, etc. –Rational long term approach needs to be thought out

4 Outline Big Picture Big Picture Java AST Issues Java AST Issues Binding Issues Binding Issues Analysis Issues (effects) Analysis Issues (effects) Plug-In Approach Plug-In Approach

5 Big picture “Eclipse” “Fluid” EclipseFluid CVS/Source IR Source Code Java AST IR Store Project (jdt.core) UI Java AST UI Java OP Plugin bind analysis CM/Source “Centered” src round-trip Transient AST; Binding is info only IR “Centered” No src round- trip “static” IR; binding as link To declaration Compiler/debugger/etc.

6 Java AST issues Approach: create in the IR “exactly” what we create today (adding 1.4 statements) Approach: create in the IR “exactly” what we create today (adding 1.4 statements) –Crucial to avoiding vast analysis code changes –Memory efficacy to be solved “later” (ironic) Tim built two adapters to create IR from Eclipse information (lots of help from Edwin/John): Tim built two adapters to create IR from Eclipse information (lots of help from Edwin/John): –Java source code adapter (2.2KSLOC) –Type adapter (avoids Jar translation) (0.5KSLOC) Fixed a few bugs in current AST… Fixed a few bugs in current AST… –Testing adapters a gigantic memory pig! Issues: A few slides of interesting items… Issues: A few slides of interesting items…

7 Fluid’s Java “.op” files Very easy to change, at least until large amounts of code depend upon them  Very easy to change, at least until large amounts of code depend upon them  No “JavaDoc” (example…)  No “JavaDoc” (example…)  Optional “things” create extra nodes  Optional “things” create extra nodes  –Handling inconsistent: “IfStatement” has no else, “IfElseStatement” does“IfStatement” has no else, “IfElseStatement” does “MethodDeclaration” has “OptMethodBody” which can be a “MethodBody” or a “NoMethodBody”“MethodDeclaration” has “OptMethodBody” which can be a “MethodBody” or a “NoMethodBody” Binding required to build useful AST: unneeded dependency, source loss (example…)  Binding required to build useful AST: unneeded dependency, source loss (example…) 

8 Example: “if” statement Note: Fluid uses “IfStatement” (shown) and “IfElseStatement” Note: Eclipse uses “null” returns for optional things, like an “else”

9 Example: binder/source loss

10 Eclipse Java AST problems (bug#20865) Null pointer when binding (bug#20865) Null pointer when binding –Fixed: target release Eclipse (bug#21916) Incorrect “for” variable declaration (bug#21916) Incorrect “for” variable declaration –for (int i = 0, j = 0 ;;) <- Source code –for (int i = 0, int j = 0 ;;) <- Eclipse rendition –Fixed: target release Eclipse 2.1 (compiler problems) (bug#22132) FieldAccess only for “this.f” (bug#22132) FieldAccess only for “this.f” –I proposed removing FieldAccess—use QualifiedName instead and bind to determine it is a field reference Fluid works around all these problems so it is usable on Eclipse 2.0 Fluid works around all these problems so it is usable on Eclipse 2.0

11 Binding issues Approach: Wrap Eclipse binder for use by Fluid Approach: Wrap Eclipse binder for use by Fluid Issues: Issues: –Eclipse binder design incompatible with Fluid design –Eclipse “abstract” binding (avoids AST loads) –Fluid “concrete” link to declaration in IR Requires loading of binary and source into IRRequires loading of binary and source into IR –Tim didn’t understand Fluid design very well, until well into the second week of work Tim/Edwin hashed out a “cut-point” and Edwin built “glue” to existing interface…it works Tim/Edwin hashed out a “cut-point” and Edwin built “glue” to existing interface…it works

12 Analysis issues Approach: Use Aaron’s effects analysis demo to “test” all Eclipse/Fluid work, and Eclipse should be “hidden” from analysis code Approach: Use Aaron’s effects analysis demo to “test” all Eclipse/Fluid work, and Eclipse should be “hidden” from analysis code Issues: Issues: –Integration last week flushed out LOTS of bugs in Eclipse AST translation and binding! –Code to useful analysis/UI loop completed! –Aaron even started getting analysis to understand new IR constructs (like the assert statement) –Version problem/Swing on Linux/others?

13 Eclipse plug-in approach Approach: Get Fluid code into Eclipse in a way allowing “future-work” with both code bases Approach: Get Fluid code into Eclipse in a way allowing “future-work” with both code bases We briefly used a “Fluid.jar” but abandoned this approach because of lack of “side-by-side” debugging of Eclipse and Fluid code. We briefly used a “Fluid.jar” but abandoned this approach because of lack of “side-by-side” debugging of Eclipse and Fluid code. Fluid code base is a “passive” plug-in to Eclipse Fluid code base is a “passive” plug-in to Eclipse A second plug-in is required to “run” fluid code A second plug-in is required to “run” fluid code –This plug-in would have a UI and be a “driver” Our effects demo uses “FluidPlug” and “edu.cmu.cs.fluid.effects” plug-in together Our effects demo uses “FluidPlug” and “edu.cmu.cs.fluid.effects” plug-in together

14 Way ahead Discussion Discussion –Fluid is quickly becoming dependent upon Eclipse (albeit, so far from behind an “abstraction” wall) 1.4 upgrade of parser and binder, from existing Fluid code base, would be time consuming.1.4 upgrade of parser and binder, from existing Fluid code base, would be time consuming. –Tough (read lots of code) to bring IR back into Eclipse (we don’t yet understand the Eclipse change model) – IR versioning model is far and away more sophisticated than what we see (so far) in Eclipse Eclipse/Fluid AST mapping is not “one-to-one”Eclipse/Fluid AST mapping is not “one-to-one” –Edwin/Aaron Thoughts?


Download ppt "Fluid Eclipse Summer Work Issues, Lessons Learned, Way Ahead."

Similar presentations


Ads by Google