JDT Summit 2006

Date: July, 10th - 12th
Location: Saint-Nazaire, France

Last revised 17:50 CET December 14, 2006 by Martin

Participants
Topics
Various Summit Notes

Participants

• Daniel Megert
• Darin Wright (partially via phone)
• David Audel
• Eric Jodet (might not be here)
• Frederic Fusier
• Jerome Lanneluc
• Markus Keller
• Martin Aeschlimann
• Maxime Daniel
• Olivier Thomann
• Philippe Mulet

Discussion Topics

This document lists the discussion topics for the JDT Summit in no particular order.
Italic green means notes about the discussion and decisions during the summit.

Java SE 6 (Wednesday morning / started Tuesday afternoon)

• What will be the new Java 6 features and what support do we have to add for 3.3.
• Debug features to expose:
  • Heap walking
    According to Darin, McQ says we should do what makes sense.
    ⇒ 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.
  • force early return, monitor access/release
    
• Script integration in Java 6 (JSR 223): Should we start looking into tooling support for JavaScript?
  ⇒ currently not part of the JDT scope. No action for 3.3.
  

Java SE 7 (Wednesday morning)

Code Assist (Tuesday morning)

• improve code assist when import missing (JDT Core: bug 44984 JDT Text: bug 107496)
  Might be doable for local variables and eventually casts but most likely not for fields.
  ⇒ JDT Core will investigate and try to provide a solution.
  
• code assist inserting code templates, e.g. (bug 97912)
• provide better support to add a cast (bug 54980)
  Should not go into code assist but into quick assist. Triggers could be: "(x" and "(x.".
  ⇒ Up to JDT UI whether to tackle this item for 3.3.
  ⇒ JDT Text will experiment with a quick assist/fix content assist proposal computer (bug 151061)
• code assist for declarations that are already used later in the code (bug 150228):

  	int f<code assist>
  	System.out.print(foo);
  

  ⇒ 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
• provide code assist context: AST or other way
  • need to know what fields, methods, variables are currently defined (use case: getter/setter proposals)
  • need the current statements (use case: annotation codeassist, method argumnet code assist)
  ⇒ 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:
  • Provide IJavaElements with updated source positions (problem: Will have to use a special working copy owner)
  • Provide a sparse AST DOM (only declarations, no statements)
  • Provide a statement recovered AST DOM with nodes for the current method (to be evaluated if statement recovery can really help here)
  • Provide a custom AST DOM (new AST level) with extra recovered nodes
  If not JDT UI could fix the getter/setter bug by waiting for the shared AST. (Original bug is bug 110181)
  

JavaBean Support (Monday morning)

Compiler

• general problem: how to specify the ignore list to work with false positives (Java Annotations, Javadoc tag, comment tags)
  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.
  ⇒ JDT UI will investigate into support for a shared "annotation" support for models.
  
• more advanced warnings:
  • NotNull, Nullable
  • overriding methods that do not call super
  • API rules: Do not instantiate, implement
• tune the existing checks to avoid false positives: Not null, thrown exception, unused parameter

AST (Monday morning)

• Need a more flexible way to create multiple ASTs
  • General problem: We don't know all CU when starting the AST queue
  • 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
  ⇒ 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. bug 150657 (Targeted for 3.3 M4)
• 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.
  •  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.
  • 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.
  ⇒ 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? (bug 124662) (Targeted for 3.3 M4)

• Compilation participation still not solved
  • Need AST on build if a code audits or APT wants to do anything reasonable
  • For performance reasons we need a way of sharing these ASTs
  • 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
  ⇒ JDT Core will might look into this if requested though performance consequences may prove impossible.
• find and create bindings in existing binding environments
  • type binding with higher dimension (bug 148224) (Targeted for 3.3 M4)
  • find type binding by name or key
  ⇒ JDT UI should just enter a bug (bug 156871)
  • create or compose type binding in binding environment of AST (bug 40096)
  ⇒ Can be tackled together with bug 150657 (see AST first item)
• offer bindings also when some information is missing
  • variable bindings when variable type is unresolved (bug 149567)
  ⇒ JDT Core will try to provide problem bindings instead of 'null'. Same problems would be reported with equal problem nodes.

Buildpath (Monday afternoon, Darin)

• exclusion/inclusion filters also for libraries (bug 119419
  • OSGI class loader allows hiding of types
  ⇒ JDT Core might look into this (low prio)
• API rules: What types/methods are API
  •  Make refactorings API aware: warn when API is modified
  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.
  ⇒ No decision so far.
• Improve classpath variables
  • Can be marked as deprecated (bug 138599) (Targeted for 3.3 M3)
  ⇒ Could be that a container initializer is able to resolve some variable, but if doing so it is deprecated then... ?
  • Can be marked as non modifiable
  ⇒ JDT UI should enter a bug with precise requirement : (bug 156226) (Targeted for 3.3 M3)
  • Allow classpath variable to map to platform and/or environment variables
  ⇒ Could be handled directly in debug JRE initializer ?
  ⇒ JDT Core will provide this.
• Improve classpath containers
  • Let containers define what is configurable/not configurable: Path, which attributes (bug 168077)
  • Allow containers to contain containers, variables and class folders
  ⇒ JDT Core will provide new API
• Solve the JRE - compliance gap
  • Specify compliance in classpath?
  • Move JRE container to jdt.core? ⇒ Won't happen.
  See item 'Leverage Execution Environment over JRE'

API

• common supertype for ICompilationUnit and IClassFile
  • bug 125504 (Targeted for 3.3 M3)
  ⇒ We will ask Jim, if he gives a go then JDT UI will provide the patch for JDT Core
  
• Applying edits to a ICompilationUnit
  • bug 117694 (Targeted for 3.3 M3)
  ⇒ difficult, needs more discussions
• Java model access to annotations
  • bug 79112
  ⇒ jdt.core will look at this
• Provide help with TypeNameRequestor result
  • bug 148380 (Released for 3.3 M3)
  ⇒ Sounds resonable, jdt.core will look at this

Search (Wednesday afternoon)

• Optimizing type indicator decorator: Find all types for a given resource
  ⇒ Martin will use new API that JDT Core will provide, see bug 150393.
• Static methods / fields index to offer organize imports with static imports
  Should not be a separate index but in the current one but in a separate category
  ⇒ no changes to the indexer: according to Philippe organize import can be done with the current infrastructure.
  ⇒ JDT Text and JDT UI will have to add a new 'add static imports' option which does the static import if appropriate.
  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.
  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 bug 152123 argueing that jdt.core is best suited to provide this.
  
• If search builds AST on search: API to get AST after search? (motivation: semantic search)
  ⇒ no actions for now - see below for details.
  

Semantic Search / Search Templates (Wednesday afternoon)

• An advanced search to allow users to formulate complex searches on the AST like
  • All invocations of NLS.format(...) that pass a string literal as first argument
  • All invocations of NLS.format(...) that pass a constant that is not in a given properties file
  • All invocations of NLS.format(...) that are possibly 'null'
  • All catch blocks for CoreExpression that have an empty body
  • All implementors of setVisible that do not call super
• 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
• Related areas: Custom code audits, generic refactorings

Code Audit Integration (Wednesday afternoon)

• 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.
• the basic code audit infrastructure needs to be at the LTK layer with JDT specific support built-on top of it.

Improve the look and feel of JDT UI (Tuesday afternoon)

• Use the new SWT capabilities in our views: different colors / styles in trees and tables
• Lightweight dialogs for refactoring (bug 92322)

Launch config templates (Tuesday afternoon)

Leverage Execution Environment over JRE (Monday afternoon, with Darin)

• Don't select a JRE in the build path wizards but a execution environment
• Combine compliance with EE
• Group JRE's by EE

Bindings for non-visible members (Tuesday afternoon, with Darin)

Evaluations without Java project, or with modified build path (Tuesday afternoon, with Darin)

Scrapbook evaluation enhancements (Tuesday afternoon, with Darin)

Scrapbook editing enhancements (Tuesday afternoon, with Darin)

Debugger usability issues (Tuesday afternoon, with Darin)

• Changes in Variables view often not shown i.e. not highlighted - here's a simple scenario:
  1. import JUnit 3.8.1
  2. open type junit.samples.VectorTest in the editor and set a breakpoint in the method setUp()
  3. now start to debug VectorTest
  4. once the breakpoint is hit press F6 and observe: the change is highlighted in the Variables view
  5. press F6 and observe: the next change is highlighted in the Variables view
  6. press F6 and observe: nothing highlighted in the Variables view
  7. in the Variables view expand fFull and observe: nothing highlighted
  As a user I would expect that the node is auto-expanding and the changes highlighted.
  ⇒ 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".
  

Populating the JavaModel

Formatting DOM AST (Monday)

Planned refactorings (Wednesday morning)

More flexible project layout (Monday afternoon)

Improve compiler fault-tolerance (Wednesday morning)

Batch Compiler (Wednesday morning)

Provide a more useful class file viewer (Discussed between Dani and Olivier only)

• 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.
• 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.
• 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.

Bug Wishes (Tuesday morning)

• From Text to JDT Core
  • improve "Unnecessary declaration of thrown checked exceptions" (bug 73244)
    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.
    
  • improve handling of constructor proposals (bug 83392)
    Talked with David: still no better support from the model that would allow to do this in a performant way.
    ⇒ No action for this PR but reopened bug 6930 to investigate simple constructor support
  • code assist should propose types even if there's no initial character(s) (bug 102875)
    ⇒ JDT Core will fix this
    
  • [formatting] each format shifts code inside <pre> one space to the right (bug 99738)
    ⇒ Olivier plans to fix this for 3.3 together with other bugs in the formatter
    
  • Java model gives different results (bug 129584)
    ⇒ JDT Core will investigate
• From Text to JDT Debug
  • [variables] Variables view should offer Auto-Expand (bug 131931)
    ⇒ Debug will add an option to the Variables view that allows to specify the expand level (see also above)

post-mortem discussion