| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html><head> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <meta content="Dani" name="author"><title>JDT Summit July 2006</title> |
| |
| <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> |
| <style type="text/css"> |
| <!-- |
| .Notes { font-style: italic; color: rgb(0, 102, 0); } |
| --> |
| </style> |
| </head> |
| <body><h1>JDT Summit 2006</h1> |
| <p>Date: July, 10th - 12th<br> |
| Location: Saint-Nazaire, France</p> |
| |
| <p>Last revised 17:50 CET December 14, 2006 by Martin</p> |
| <p> |
| <a href="#participants">Participants</a><br> |
| <a href="#topics">Topics</a><br> |
| <a href="#notes">Various Summit Notes</a><br> |
| </p> |
| |
| |
| <h3> |
| <a name="participants"></a>Participants |
| </h3> |
| <ul> |
| <li>Daniel Megert</li> |
| <li>Darin Wright (partially via phone)</li> |
| <li>David Audel</li> |
| <li>Eric Jodet (might not be here)</li> |
| <li>Frederic Fusier</li> |
| <li>Jerome Lanneluc</li> |
| <li>Markus Keller</li> |
| <li>Martin Aeschlimann</li> |
| <li>Maxime Daniel</li> |
| <li>Olivier Thomann</li> |
| <li>Philippe Mulet</li> |
| </ul> |
| |
| |
| <h3><a name="topics"></a>Discussion Topics</h3> |
| <p>This document lists the discussion topics for the JDT Summit in no particular order.<br> |
| <span class="Notes">Italic green means notes about the discussion and decisions during the summit.</span><br> |
| |
| </p> |
| |
| |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Java SE 6<span class="Notes"> (Wednesday morning / started Tuesday afternoon)</span></h4> |
| |
| <ul> |
| <li>What will be the new Java 6 features and what support do we have to add for 3.3.</li> |
| <li>Debug features to expose: |
| <ul> |
| <li>Heap walking<br> |
| <span class="Notes"> |
| According to Darin, McQ says we should do what makes sense.<br> |
| ⇒ Debug should expose the set of things that |
| all Java programmers will want. For example, we could start with a feature to "show references" to an object |
| in the variables view, or an action to "get all instances" of a type. This would be in place of a full blown "heap walking" |
| perspective.</span> |
| </li> |
| </ul> |
| <ul> |
| <li>force early return, monitor access/release<br> |
| </li> |
| </ul> |
| </li> |
| <li>Script integration in Java 6 (JSR 223): Should we start looking into tooling support for JavaScript?<br> |
| <span class="Notes">⇒ currently not part of the JDT scope. No action for 3.3.</span><br> |
| </li> |
| </ul> |
| |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Java SE 7<span class="Notes"> (Wednesday morning)</span><br> |
| </h4> |
| What will be the new Java 7 features and what support do we have to |
| add for 3.3.<br> |
| <span class="Notes">⇒ This will contain many big changes/additions (e.g. XML inside Java code) which is out of scope for 3.3.</span><br> |
| |
| |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Code Assist<span class="Notes"> (Tuesday morning)</span><br> |
| </h4> |
| <ul> |
| <li>improve code assist when import missing (JDT Core: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=44984">bug 44984</a> JDT Text: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=107496">bug 107496</a>)<br> |
| <span class="Notes">Might be doable for local variables and eventually casts but most likely not for fields.<br> |
| ⇒ |
| JDT Core will investigate and try to provide a solution.</span><br> |
| </li> |
| <li style="text-decoration: line-through;">code assist inserting code templates, e.g. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=97912">bug 97912</a>)</li> |
| <li>provide better support to add a cast (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=54980">bug 54980</a>)<br> |
| <span class="Notes"> |
| Should not go into code assist but into quick assist. Triggers could be: "(x" and "(x.".<br> |
| ⇒ Up to JDT UI whether to tackle this item for 3.3.<br> |
| ⇒ JDT Text will experiment with a quick assist/fix content assist proposal computer (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=151061">bug 151061</a>) |
| </span> |
| </li> |
| <li>code assist for declarations that are already used later in the code (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150228">bug 150228</a>): |
| <pre> int f<code assist><br> System.out.print(foo);<br></pre><span class="Notes">⇒ JDT Core will investigate and try to provide the unresolved local variables. |
| Idea: JDT Text could investigate to provide a proposal computer that wraps quick assist</span> |
| |
| </li> |
| <li>provide code assist context: AST or other way |
| <ul> |
| <li>need to know what fields, methods, variables are currently defined (use case: getter/setter proposals)</li> |
| <li>need the current statements (use case: annotation codeassist, method argumnet code assist)</li> |
| </ul><span class="Notes">⇒ |
| JDT UI and JDT Core will work together and check whether a Java element |
| or a diet AST would help to resolve the problem. |
| Discussed approaches:<ul><li>Provide IJavaElements with updated source positions (problem: Will have to use a special working copy owner)</li> |
| <li>Provide a sparse AST DOM (only declarations, no statements)</li> |
| <li>Provide a statement recovered AST DOM with nodes for the current method (to be evaluated if statement recovery can really help here)</li> |
| <li>Provide a custom AST DOM (new AST level) with extra recovered nodes</li> |
| </ul> |
| If not JDT UI could fix the getter/setter bug by waiting for the shared AST. |
| (Original bug is <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=110181">bug 110181</a>) </span><br> |
| </li> |
| </ul> |
| |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> JavaBean Support<span class="Notes"> (Monday morning)</span><br> |
| </h4> |
| There are several feature requests asking for better support for JavaBean Property handlig, e.g. enhanced |
| code assist, templates, Outline grouping and a JavaBean wizard. |
| <br> |
| We should discuss and decide whether we want to do something in that area for 3.3.<br> |
| <br> |
| <span class="Notes"> |
| ⇒ based on the experience JDT Text & UI will get from the competitive analyses, JDT Text & UI will investigate minimal support limited to 3 days. No action for JDT Core at this point.</span><br> |
| |
| |
| |
| <h4>Compiler<br> |
| </h4> |
| <ul> |
| |
| <li>general problem: how to specify the ignore list to work with false positives (Java Annotations, Javadoc tag, comment tags)<br> |
| <span class="Notes">General agreement that this is |
| useful. First idea to flag it inside the code with @SuppressWarnings |
| block comments was rejected because it would pollute the code, be hard |
| for JDT Core and be a JDT solution only.</span><br> |
| <span class="Notes">⇒ |
| JDT UI will investigate into support for a shared "annotation" support for models.</span><br> |
| |
| </li><li>more advanced warnings: |
| <ul> |
| <li>NotNull, Nullable</li> |
| <li>overriding methods that do not call super</li> |
| <li>API rules: Do not instantiate, implement</li> |
| </ul> |
| </li> |
| <li>tune the existing checks to avoid false positives: Not null, thrown exception, unused parameter</li> |
| |
| </ul> |
| |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> AST<span class="Notes"> (Monday morning)</span><br> |
| </h4> |
| <ul> |
| <li><a name="AST1"/>Need a more flexible way to create multiple ASTs |
| <ul> |
| <li>General problem: We don't know all CU when starting the AST queue</li> |
| <li>Performance |
| problem: How many ASTs can we build before we run OOM. Would be nice if |
| core has a mechanism to manage the referenced bindings</li> |
| </ul> |
| <span class="Notes">⇒ JDT Core will look at this. Idea is to provide a binding environment object that can be reused when creating an AST. |
| JDT Core will hide the recreation of the compiler bindings in case of memory problems or when a AST is requested for a |
| already known binding. <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150657">bug 150657</a> (Targeted for 3.3 M4) |
| </span> |
| </li> |
| |
| |
| <li>AST sharing problem still not solved. The solution we implemented in 3.2 |
| was that Java element listeners observe the delta to get the AST. |
| <ul> |
| <li> Problem: The caller of 'reconcile' defines if an |
| AST is generated and what kind (AST level, bindings, recovery) is is. |
| 50% of callers don't care for an AST, and so the delta also doesn't |
| contain one.</li> |
| <li>Suggestion: The working copy owner (Java |
| editor in the primary case) should decide if and what kind of ASTs are |
| provided in the Java element delta after a reconcile.</li> |
| </ul> |
| <span class="Notes">⇒ |
| JDT Core will change the code so that the primary working copy owner |
| can specify the default AST level (or none) and reconcile(...) without |
| parameters will provide the AST with the default level and also send |
| out the delta with that AST. Open questions: what happens when a client specifies the AST level? |
| <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=124662">(bug 124662)</a> (Targeted for 3.3 M4) |
| </span> |
| |
| </li> |
| </ul> |
| |
| |
| <ul> |
| |
| <li>Compilation participation still not solved |
| <ul> |
| <li>Need AST on build if a code audits or APT wants to do anything reasonable</li> |
| <li>For performance reasons we need a way of sharing these ASTs</li> |
| <li>For |
| performance reasons we need to force a certain AST kind (level, |
| bindings, recovery). Clients can use it or leave it. Creating multiple |
| AST kinds is not possible</li> |
| </ul><span class="Notes">⇒ |
| JDT Core will might look into this if requested though performance consequences may prove impossible.</span> |
| </li> |
| |
| <li>find and create bindings in existing binding environments |
| <ul> |
| <li>type binding with higher dimension (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=148224">bug 148224</a>) (Targeted for 3.3 M4)</li> |
| <li>find type binding by name or key</li> <span class="Notes">⇒ JDT UI should just enter a bug (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=156871">bug 156871</a>)</span> |
| <li>create or compose type binding in binding environment of AST (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=40096">bug 40096</a>)</li> |
| </ul> |
| <span class="Notes">⇒ Can be tackled together with <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150657">bug 150657</a> (<a href="#AST1">see AST first item</a>)</span> |
| |
| </li> |
| <li>offer bindings also when some information is missing |
| <ul> |
| <li>variable bindings when variable type is unresolved (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=149567">bug 149567</a>)</li> |
| </ul><span class="Notes">⇒ JDT Core will try to provide problem bindings instead of 'null'. Same problems would be reported with equal problem nodes.</span> |
| </li> |
| |
| |
| </ul> |
| |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Buildpath<span class="Notes"> (Monday afternoon, Darin)</span><br> |
| </h4> |
| <ul> |
| <li>exclusion/inclusion filters also for libraries (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=119419">bug 119419</a> |
| <ul> |
| <li>OSGI class loader allows hiding of types</li> |
| </ul><span class="Notes">⇒ JDT Core might look into this (low prio)</span> |
| </li> |
| |
| |
| <li>API rules: What types/methods are API |
| <ul> |
| <li> Make refactorings API aware: warn when API is modified</li> |
| </ul> |
| |
| <span class="Notes"> Could be annotated in |
| source (Javadoc or Annotations) or on the build path. Could generate an |
| API description out of it (e.g. component.xml). Could have action to |
| set the access restrictions out of an API. Must consider that MANIFEST.MF and component.xml don't surface the same information. |
| <br>⇒ No decision so far. |
| </span> |
| |
| </li> |
| |
| <li>Improve classpath variables |
| <ul> |
| <li>Can be marked as deprecated (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=138599">bug 138599</a>) (Targeted for 3.3 M3)</li> |
| <span class="Notes">⇒ Could be that a container initializer is able to resolve some variable, but if doing so it is deprecated then... ?</span> |
| <li>Can be marked as non modifiable</li> |
| <span class="Notes">⇒ JDT UI should enter a bug with precise requirement : (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=138599">bug 156226</a>) (Targeted for 3.3 M3)</span> |
| <li>Allow classpath variable to map to platform and/or environment variables</li> |
| <span class="Notes">⇒ Could be handled directly in debug JRE initializer ?</span> |
| </ul> |
| <span class="Notes">⇒ JDT Core will provide this.</span> |
| </li> |
| <li>Improve classpath containers |
| <ul> |
| <li>Let containers define what is configurable/not configurable: Path, which attributes (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=168077">bug 168077</a>)</li> |
| <li>Allow containers to contain containers, variables and class folders</li> |
| </ul> |
| <span class="Notes">⇒ JDT Core will provide new API</span> |
| </li> |
| <li>Solve the JRE - compliance gap |
| <ul> |
| <li>Specify compliance in classpath?</li> |
| <li>Move JRE container to jdt.core? |
| <span class="Notes">⇒ Won't happen.</span> |
| </li> |
| </ul> |
| <span class="Notes">See item 'Leverage Execution Environment over JRE'</span> |
| |
| </li> |
| |
| </ul> |
| |
| <h4>API</h4> |
| <ul> |
| <li>common supertype for ICompilationUnit and IClassFile |
| <ul> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=125504">bug 125504</a> (Targeted for 3.3 M3)</li> |
| </ul><span class="Notes">⇒ We will ask Jim, if he gives a go then JDT UI will provide the patch for JDT Core</span><br> |
| |
| </li> |
| <li>Applying edits to a ICompilationUnit |
| <ul> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=117694">bug 117694</a> (Targeted for 3.3 M3)</li> |
| </ul> |
| <span class="Notes">⇒ difficult, needs more discussions</span> |
| </li> |
| <li>Java model access to annotations |
| <ul> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=79112">bug 79112</a></li> |
| </ul> |
| <span class="Notes">⇒ jdt.core will look at this</span> |
| </li> |
| <li>Provide help with TypeNameRequestor result |
| <ul> |
| <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=148380">bug 148380</a> (Released for 3.3 M3)</li> |
| </ul> |
| <span class="Notes">⇒ Sounds resonable, jdt.core will look at this</span> |
| </li> |
| |
| </ul> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Search<span class="Notes"> (Wednesday afternoon)</span></h4> |
| |
| <ul> |
| <li>Optimizing type indicator decorator: Find all types for a given resource<br> |
| <span class="Notes">⇒ Martin will use new API that JDT Core will provide, see <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150393">bug 150393</a>.</span> |
| </li> |
| <li>Static methods / fields index to offer organize imports with static imports<br> |
| <span class="Notes">Should not be a separate index but in the current one but in a separate category<br> |
| ⇒ no changes to the indexer: according to Philippe organize import can be done with the current infrastructure.<br> |
| ⇒ <strike>JDT Text and JDT UI will have to add a new 'add static imports' option which does the static import if appropriate.</strike><br> |
| WAIT: when we discussed this with the other JDT Text and UI members another idea came up by Dirk: we could simply provide a whitelist where the |
| user could enter the static types and/or members he'd like to use.<br> |
| After discussion with Philippe he says it's a good idea but the whitelist should be kept in JDT UI or Text land. JDT Core is |
| willing to provide more (content assist) context information if needed. Martin created <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=152123">bug 152123</a> argueing that |
| jdt.core is best suited to provide this. |
| </span><br> |
| |
| </li> |
| <li>If search builds AST on search: API to get AST after search? (motivation: semantic search)<br> |
| <span class="Notes">⇒ no actions for now - see below for details.</span><br> |
| </li> |
| </ul> |
| |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Semantic Search / Search Templates <span class="Notes">(Wednesday afternoon)</span></h4> |
| |
| Power search would require to support more evolved search patterns. Can |
| we sketch usecases and ways to provide some degree of support which |
| could be evolved further to add more coverage ? Also what would a UI |
| for it look like (script-based ?) |
| <ul> |
| <li>An advanced search to allow users to formulate complex searches on the AST like |
| <ul> |
| <li>All invocations of NLS.format(...) that pass a string literal as first argument</li> |
| <li>All invocations of NLS.format(...) that pass a constant that is not in a given properties file</li> |
| <li>All invocations of NLS.format(...) that are possibly 'null'</li> |
| <li>All catch blocks for CoreExpression that have an empty body</li> |
| <li>All implementors of setVisible that do not call super</li> |
| </ul> |
| </li> |
| <li>We |
| believe that a snippet based approach will not give is this power: |
| We're looking at programmatic approches at the moment: JQuery, JScript, |
| functional languages</li> |
| <li>Related areas: Custom code audits, generic refactorings</li> |
| </ul><span class="Notes">⇒ JDT UI should finish and present the prototype so that we can provide feedback and decide how to continue.</span> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Code Audit Integration <span class="Notes">(Wednesday afternoon)</span></h4> |
| |
| <ul> |
| <li> The goal is to standardize how and when code audits (our |
| own and contributed) are invoked and presented in the UI as well as to |
| provide core infrastructure. Some code audits can be computed 'as you |
| type', others require deep analysis that can't be done while building |
| but has to be kicked on by the user or other events. We have to discuss |
| where and how code audit result are presented (e.g. in the problems |
| view or in a new code audit view) and if we want to provide |
| infrastructure for the code audit preference pages. |
| Core infrastructure would allow code audits to share resources as the |
| AST. </li> |
| <li>the basic code audit infrastructure needs to be at the LTK layer with JDT specific support built-on top of it.</li> |
| |
| </ul><span class="Notes">⇒ needs to be clarified first</span> |
| |
| <h4>Improve the look and feel of JDT UI <span class="Notes">(Tuesday afternoon)</span><br> |
| </h4> |
| We should discuss where it makes sense to adopt new features provided by the Platform and where to further beautify the JDT UI. |
| <ul> |
| <li>Use the new SWT capabilities in our views: different colors / styles in trees and tables</li> |
| <li>Lightweight dialogs for refactoring (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=92322">bug 92322</a>)</li> |
| </ul> |
| |
| <span class="Notes"> |
| <p> |
| The following are wishes from JDT Core members to JDT Text and JDT UI: |
| </p> |
| Philippe: |
| <ul> |
| <li>allow to highlight code pieces that belong together with with vertical lines (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=84878">bug 84878</a>)</li> |
| <li>change history view, so after a refactoring it is possible to revisit the last changes (bug?)</li> |
| |
| </ul> |
| Jerome: |
| <ul> |
| <li>non-modal refactoring dialogs</li> |
| <li>allow to change the refactoring output</li> |
| </ul> |
| Olivier: |
| <ul> |
| <li>smart paste into "SELECTED" should remove the text in the string (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150249">bug 150249</a>)</li> |
| </ul> |
| Maxime: |
| <ul> |
| <li>allow to turn a code selection into string(s) so it can be used as a test case string and the other way around (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150807">bug 150807</a>)</li> |
| </li> |
| </ul> |
| </span> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Launch config templates<span class="Notes"> (Tuesday afternoon)</span><br> |
| </h4> |
| Users want to define certain default values (e.g. compiler arguments) for a launch config type |
| (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=41353">bug 41353</a>).<br> |
| <span class="Notes">Discussed full-fledged inheritance for individual launch config properties, |
| but this was found to be too much for the UI (tristate everywhere, client-contributed tabs would be broken) |
| as well as for the model (e.g. what if base template is not shared but child template is, etc.). |
| <br>⇒ Debug will implement a simple copy-based solution where new launch configs can be based |
| on an existing launch config. New launch configs will not be connected to template after initial copying of attributes. |
| <br>Note:</em> According to the current 3.3 draft plan this will not be a committed item. |
| </span> |
| <br> |
| |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Leverage Execution Environment over JRE<span class="Notes"> (Monday afternoon, with Darin)</span><br> |
| </h4> |
| <ul> |
| <li>Don't select a JRE in the build path wizards but a execution environment</li> |
| <li>Combine compliance with EE</li> |
| <li>Group JRE's by EE</li> |
| </ul><span class="Notes"> |
| ⇒ Darin will talk with Wassim and Jeff.</span><br> |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Bindings for non-visible members<span class="Notes"> (Tuesday afternoon, with Darin)</span></h4> |
| |
| Compiling snippets that have a private field reference from a |
| superclass, do not have resolved bindings. For example, the snippet |
| "fName.length()" when compiled in the context of VectorTest, which |
| references fName from TestCase, does not have a resolved method binding |
| for "length()". I don't think that fName has a resolved type binding |
| either. Philippe thought this information was availale, but might not |
| be in the AST/DOM.<br> |
| <span class="Notes"> |
| ⇒ Darin to enter a bug for Olivier (should already be there)</span><br> |
| <br> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Evaluations without Java project, or with modified build path<span class="Notes"> (Tuesday afternoon, with Darin)</span><br> |
| </h4>It |
| is possible to debug an application with a runtime classpath that does |
| not match a project's build path, or to debug an application that has |
| no associated projects in the workspace. Would it be possible to |
| perform evaluations by having the debugger perform name lookups, to |
| support evaluations that reflect the run(debug)-time?<br> |
| <span class="Notes">Debug can get the AST from the reconcile.</span><br> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Scrapbook evaluation enhancements (<span class="Notes">Tuesday afternoon, with Darin)</span></h4> |
| |
| Support for import statements (could be done by debugger), breakpoints, source display (stepping, etc), |
| |
| |
| <br> |
| <span class="Notes">⇒ Darin said, Debug can use separate panes for imports, check the presence of Debug attributes so that they map on the right line</span><br> |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Scrapbook editing enhancements<span class="Notes"> (Tuesday afternoon, with Darin)</span></h4> |
| Separate code from |
| evaluation results for coloring/styling, support to auto insert closing |
| bracket/quote, quick fix (assign to local etc), red squiggles, CTRL-T |
| on selected type (hover type hierarchy), toggle (un)block comments, |
| shift left/right, format, organize imports, rename selected variable in |
| file. - these things should work anywhere an evaluation can be |
| performed - scrapbook, display view, variable details pane, expression |
| detail pane, conditions, detail formatters, logical structures...<br> |
| <span class="Notes">⇒ Dani and Darin will check whether we can get rid of the scrapbook editor entirely (eval hook in the Java editor?)</span><br> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Debugger usability issues<span class="Notes"> (Tuesday afternoon, with Darin)</span></h4> |
| |
| Open discussion/suggestions for usability improvements in the Java debugger |
| <ul> |
| <li>Changes in Variables view often not shown i.e. not highlighted - here's a simple scenario: |
| <ol> |
| <li>import JUnit 3.8.1</li> |
| <li>open type <code>junit.samples.VectorTest</code> in the editor and set a breakpoint in the method <code>setUp()</code></li> |
| <li>now start to debug <code>VectorTest</code></li> |
| <li>once the breakpoint is hit press F6 and observe: the change is highlighted in the Variables view</li> |
| <li>press F6 and observe: the next change is highlighted in the Variables view</li> |
| <li>press F6 and observe: nothing highlighted in the Variables view</li> |
| <li>in the Variables view expand <code>fFull</code> and observe: nothing highlighted</li> |
| </ol> |
| As a user I would expect that the node is auto-expanding and the changes highlighted.<br> |
| <span class="Notes">⇒ |
| Debug will add a slider to the Variables view where users can define |
| how deep the auto-expansion will be. Max. would mean "expand all".</span><br> |
| |
| </li> |
| </ul> |
| |
| |
| <h4>Populating the JavaModel<br> |
| </h4>Recent additions, like Java type |
| indicator in label decoration, are changing the assumptions on |
| populating the Java model. Given the cache got tuned for certain usage, |
| we should make sure it is aligned with current story, and planned |
| evolutions. Clearly eager is considered bad. We should discuss |
| alternative queries, and or complementary API addition (a la type |
| hierarchy getCachedFlags() --> |
| ICompilationUnit#getCachedFlags(IType/null to denote first type). |
| <span class="Notes">The type indicator has now been changed to use the search index (for 3.3 M1). Also in discussion is new API (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150393">bug 159393</a>)</span> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Formatting DOM AST<span class="Notes"> (Monday)</span></h4> |
| |
| Current formatter implementation is based on compiler internal AST. We |
| should discuss the benefits for providing a DOM AST solution instead. |
| What is the performance overhead, what are the consequences/benefits |
| for DOM AST users ?<br> |
| <span class="Notes">⇒ JDT Core will not convert the |
| formatter to DOM AST since it does not give immediate benefits unless |
| formatter bugs get fix that benefit from it, is neither needed by JDT |
| Text nor JDT UI and has performance impacts. JDT Core will try to fix |
| the bugs in the formatter with another approach. This decision might change in the future should new requests arise.</span> |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Planned refactorings<span class="Notes"> (Wednesday morning)</span><br> |
| </h4>To anticipate API requests, it would be |
| good to explain the planned additions to refactorings. What typical new |
| operations are going to be provided, what expensive ones are becoming |
| critically used...<br> |
| <span class="Notes">According to Martin there is no |
| new JDT Core support needed at the moment, except for the support to reuse bindings (<a href="#AST1">see AST first item</a>).</span><br> |
| |
| <h4>More flexible project layout<span class="Notes"> (Monday afternoon)</span><br> |
| </h4>When adopting Eclipse, some |
| pre-existing project layouts are hard to model in Eclipse. It feels |
| this process could be eased by allowing more configurability of the |
| Java project, such as allowing custom buildpath or settings on a per |
| source folder basis; multiple source attachments per library; inclusion |
| of external resources in workspace (as opposed to linking resources |
| which is not seen by external tools); relax classpath container |
| limitations, which currently do not allow nested containers, source |
| folders etc...<br> |
| <br> |
| <span class="Notes">Philippe discussed this within the PMC and they would only accept this under a different name: "more flexible classpath layout".<br> |
| Discussed about 2 hours without any conclusion so far. Dani's idea is |
| to leave everything as is but add a super java project that could |
| contain IJavaProjects.<br> |
| ⇒ no clear path yet</span><br> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Improve compiler fault-tolerance<span class="Notes"> (Wednesday morning)</span></h4> |
| Missing types can greatly |
| deteriorate compiler output by producing too many secondary errors, |
| surface suboptimal DOM bindings, or even abort entire compilation |
| process when missing types are referenced from required classfiles. We |
| should investigate ways to improve this situation, remembering that the |
| APT Mirror API requires that bindings are still presented even in the |
| presence of missing types.<br> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Batch Compiler<span class="Notes"> (Wednesday morning)</span><br> |
| </h4>Consider batch compiler improvements triggerred |
| by its raised visibility; I think we should make a conscious effort to |
| ease the dual use of the IDE |
| and the batch compiler, keeping in mind the fact that we also need to |
| be 'javac compatible' for the batch compiler; there are also |
| improvements |
| undergoing in the way we call it; and I'd like also to consider porting |
| to the batch environment part of the work done for us by the resource |
| layers |
| in Eclipse (or else replace it by something powerful - aka consider |
| canonizing filenames, etc., cleanup design points around files accessed |
| through |
| multiple paths, consider a portable file naming scheme, etc.) |
| I think APT folks will find an interest in this in that they will |
| likely be involved into batch building uses at one point in time. And |
| UI should be helpful in rounding up batch/IDE equivalences.<br> |
| <br> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Provide a more useful class file viewer<span class="Notes"> (Discussed between Dani and Olivier only)</span><br> |
| </h4> |
| |
| <ul> |
| <li>It would be nice to have an extension point that could set |
| the viewer used to see .class file. We could imagine this extension |
| point to be used by a disassembler like JAD that provides source code |
| instead of class file structure.</li> |
| <li>The class file disassembler |
| has some "advanced" modes that cannot be triggered by the actual class |
| file viewer. Right now I don't find the contents showed as useful since |
| it doesn't provide more information than the outliner. We could have a |
| class file viewer that could benefit from the SYSTEM and DETAILED mode |
| of the disassembler with code folding for some attributes (Code |
| Attribute, RuntimeAnnotations....). This could be quite interesting.</li> |
| <li>We |
| could imagine a new view like the outliner that would show the .class |
| file contents for a compilation unit retrieving the corresponding |
| .class file. This would be very handy when debugging a problem in the |
| compiler.</li> |
| </ul> |
| See also <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=59495">bug 59495</a>.<br> |
| <span class="Notes">Clients can provide their own view on a Java class file via |
| "org.eclipse.ui.editors" extension point. There are currently no plans |
| to offer plugable views for the Class File editor.<br> |
| ⇒ JDT Text will ask legal (Adrian Cho) whether it is OK to show disassembled |
| contents and if yes, show the detailed result from the disassembler (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=3537">bug 3537</a>)</span><br> |
| |
| <h4><img src="../images/ok.gif" alt="Done" border="0" height="10" width="10"> Bug Wishes<span class="Notes"> (Tuesday morning)</span></h4> |
| |
| |
| This topic lists bugs that do not need to be discussed in detail but for which the team would like to have and would like to get |
| an answer whether this can be done and if not, why. Of course if a bug is accepted it might lead to further discussions. |
| <ul> |
| <li>From Text to JDT Core |
| <ul> |
| <li><span class="Notes">improve "Unnecessary declaration of thrown checked exceptions" (</span><a class="Dani" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=73244">bug 73244</a><span class="Notes">)</span><br class="Dani"> |
| <span class="Notes">see "Compiler" topic |
| above: instead of providing support for special cases we should find a |
| way to suppress warnings. In addition pingged the bug whether it could |
| be solved for 3.3.</span><br> |
| </li> |
| <li>improve handling of constructor proposals (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=83392">bug 83392</a>)<br> |
| <span class="Notes"> |
| Talked with David: still no better support from the model that would allow to do this in a performant way.<br> |
| ⇒ No action for this PR but reopened <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=6930">bug 6930</a> to investigate simple constructor support</span> |
| </li> |
| <li>code assist should propose types even if there's no initial character(s) (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=102875">bug 102875</a>)<br> |
| <span class="Notes">⇒ JDT Core will fix this</span><br> |
| </li> |
| <li>[formatting] each format shifts code inside <pre> one space to the right (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=99738">bug 99738</a>)<br> |
| <span class="Notes">⇒ Olivier plans to fix this for 3.3 together with other bugs in the formatter</span><br> |
| </li> |
| <li>Java model gives different results (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=129584">bug 129584</a>)<br> |
| <span class="Notes">⇒ JDT Core will investigate</span></li> |
| </ul> |
| |
| </li><li>From Text to JDT Debug |
| |
| <ul> |
| |
| <li>[variables] Variables view should offer Auto-Expand (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=131931">bug 131931</a>)<br> |
| |
| <span class="Notes">⇒ Debug will add an option to the Variables view that allows to specify the expand level (see also above)</span></li> |
| </ul> |
| </li> |
| </ul> |
| |
| |
| |
| <h4>post-mortem discussion</h4> |
| <span class="Notes">This will be done individually by JDT Core and ZRH and then consolidated.</span> |
| |
| <span class="Notes"><h3><a name="notes"></a>Various Summit Notes</h3> |
| <ul> |
| <li>initial talks about 3.3 plan, team structure</li> |
| <li>downloads</li> |
| <li>first we scheduled most of the items |
| <ul> |
| <li>diverging into discussing Java Beans feature</li> |
| </ul> |
| </li> |
| <li>started discussion with AST</li> |
| <li>Darin is part of the discussion on Monday afternoon 17h30 - 19h00</li> |
| <li>discussed possibility to switch to 5.0: most likely not possible (will probably not happen)</li> |
| <li>Olivier will continue to bring croissants for the whole team ;-)</li> |
| |
| </ul> |
| </span> |
| <br> |
| |
| |
| |
| |
| </body></html> |
