EditorPlan71

Revision as of 13:39, 5 April 2011 by Dstrupl (Talk | contribs)

Disclaimer: The content of this NetBeans development wiki page is intended for pre-planning purposes ONLY. The development, release, and timing of any feature or functionality described here should not be treated as final, and is subject to change at any time at the sole discretion of Oracle. For information about NetBeans software releases please visit the NetBeans Roadmap.

Contents

Planning for NetBeans 7.1 (JET Team)

High Level Plan

Plan for previous release

Plan for further releases

Performance

Full text index

Find Usages and related refactorings for methods and fields can be made faster (Issue 169958, Issue 120145) - a full text index would be very helpful (Tomas)

Remove obsolete code in editor

Lower the editor memory footprint by removing the old Syntax (the former version of lexer) - this work mainly includes ... and rewriting the existing java indenter

Transactional index

(Issue 182653) Use data from old index while indexing is running (where possible) Some features like Lucene Indexes already lock the index only in time of index update not during the whole indexing but the index reader client is negatively affected by the IO. Improving the index caching should help, see Improve Go To Type.

Complete Transactional Index support requires several changes:

  • The threading model of parsing has to be changed from a single dedicated parser thread to a concurrent model where the indexer (parser) is called by a non dedicated thread concurrently to the parser thread. This is an incompatible API change in the threading model which may affect existing languages depending on the single threaded model. On the other hand the Indexing API never declared the single threaded model.
  • The disk caches have to be transactional. The Lucene index supports transactions, but a custom storage implementation such as Java Signature Files have to be updated to support transactions as well. The transactional cache introduces higher IO load as the disk operations are done twice (the first time in a log phase, the second time in a commit phase - simpler).
  • The biggest problem is how to avoid OOM situations. Currently the dedicated parser thread uses VM telemetry to prevent OOME. This approach will not work as there will be more parsing threads running concurrently and consuming memory.
  • The JavaCustomIndexer and JavaBinaryIndexer have to be rewritten so that they can handle requests even before the up-to-date check is finished.

Misc performance improvements

Issue 187282 (cndreq, API) Allow to exclude embedded langs for source root

Issue 172312 (cndreq) Lucene 2.4.1 consumes more memory than it should

Issue 186744 (API) Adding library causes huge I/O load - deleting files on background does not solve the problem, it's already done on background. The rename and clean up in idleIO will work fine. But the idleIO is not an API (even friend API). It's in the MasterFS FileChangeManager. This requires an idleIO to be added at least into the ProvidedExtensions like runPriorityIO. (Tomas)

New features

JNLP and WebStart improvements

Issue 181265 Add filter warnings possibility into the output window

Misc Features

General Infrastructure Improvements

Issue 135492 Simplify Coloring Profiles creation (Maros)

Issue 144579 (cndreq, API) Add support for child nodes to MimeLookup Preferences

Issue 182388 (j2ee,API) Provide api to set the DisplayName of a Library created programmatically (Tomas)

Usability Improvements

Issue 89607 Double-click-drag-select and Triple-click-drag-select

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo