RichardMichalsky

Suggestions for Improving NB Application Development

This is an evaluation of NB Platform application development support, based on my Eclipse RCP application programming experience. This document does not cover developing modules for NB itself, nor does it (yet) take existing issues in IssueZilla into account.
APISupportInNetBeans6.7 here.
APISupportInNetBeans6.8 here.

Motivation

The implied assumption of this document is that we indeed want to encourage and help with development of NB Platform-based applications (as opposed to apisupport being there mainly for developing modules for NetBeans IDE).

Save for small toys and utilities most new desktop GUI applications are built upon some kind of framework or platform. Eclipse probably dominates the scene with RCP - e.g. search for Eclipse RCP application on http://sourceforge.net yields at the time of the writing some 40+ RCP-based applications while all 4 results of NetBeans platform application are actually modules for NB IDE, of course this is an arguable evidence. On the other hand there is a lot to be improved on both platforms.

There are some differences between Platform/IDE development and application development. Notably:

  • Platform-based projects tend to be relatively large (only then the overhead of using the platform pays back).
  • The development, especially of commercial applications, usually tends to be much more centralized in terms of overall functionality, UI and modules.
  • Typical application developer wants to know as little as possible about the platform itself.

Strong Points of NB APISupport Compared to Eclipse

  • Ant-based projects are much easier to integrate into headless build systems. There are plugins for that in Eclipse (PDE Build, PluginBuilder), the usage of which changes wildly among releases (at least up to 3.3.1) and custom modifications to build scripts are hard to do.
  • XML layers offer a little more flexibility than Eclipse extension points:
  • hierarchical nodes allow for extending format defined by another module
  • already dynamically configurable at runtime - added to Equinox in 3.3.1, AFAIK not yet supported by all plugins
  • <this layer in context> node in Projects offers very very useful view of the application, that Eclipse still lacks. More on it below.
  • Swing makes migration of existing Java applications to NB Platform easy.
  • Lookups are flexible and easy to use while retaining some type safety with class objects as keys. ServiceLocators in Eclipse use string keys and are less extensible.
  • Project Customizer lets user edit module-related properties (public packages, module dependencies, ...) right where she expects it. Eclipse can be very confusing at this point for newbie developer.

Weak Points of NB APISupport Compared to Eclipse

  • META-INF/services vs. XML layers - although working and behaving differently, in principle they do the same thing - let one module declare an "interface" (be it declarative data format or actual Java interface) and let other modules contribute their data or implementation. It is IMO needlessly confusing to force user learn how to use these two (albeit simple) concepts to do basically the same thing.
    Eclipse has Extension Points, the usage of which is explained and encouraged over and over in the docs (note that Eclipse also has OSGi services but I wonder how many RCP developers have ever heard of them).
  • XML layers are IMHO the functionality that maps directly to Eclipse extension points (not META-INF/services) and while being slightly more configurable ( see above), ext. points have some properties that make them more usable:
  • unique owner of the ext. point gives developer a hint what part of the application he contributes to and allows for:
  • Extension point schema - owner of the ext. p. must provide schema which allows IDE not only to validate that the extension is syntactically correct but also to provide rich generic editor for writing the extensions.
  • Documentation is embedded in the extension point schema, providing relevant and contextual info when writing extension.
  • IDE can show a list of available extension points along with their documentation, the list is accurate and complete without any docs-are-not-in-synch-with-code issues.
  • Application configuration - application consisting of single suite of modules (which cannot be easily shared among applications) and using single platform is not configurable enough setup even for mid-size applications. Suite chaining and custom platforms are workarounds and hard to work with.
    Eclipse has features (much like clusters in NB) - sets of modules which compose whole platform. Platform contains both "user" and "platform" modules in NB terms, Eclipse has no such notion, all modules are considered equal ;-). Modules can be included in different features, there can be multiple applications defined in the platform with different runtime configurations of enabled features and modules.

What is Missing in Both Platforms

  • Visual editing of application UI as a whole, i.e. menus, toolbars, window layout, etc. Here is IMHO the point where usual application development differs a lot from NetBeans development. While applications still benefit from the extensibility the platform offers, from my experience the application is much more often developed "as a whole" rather than by individual modules. With current support developer must usually have the big picture of the app. in his mind e.g. when adding a menu item. (TODO - link issue)

    Visual Studio has IMHO the best support in this area (would be interesting to see what Visual Studio 2008 Shell comes up with), Eclipse has (commercial) Window Builder plugin, which offers some of the mentioned functionality.
  • Smooth ORM / Persistence support in modules - haven't tried JPA in NB modules yet (see issue #128643) but I recall quite some problems with Hibernate in Eclipse RCP plugins.
  • Not apisupport-related, but not sure where to put it. I've experienced couple times that the biggest problem with new commercial application has been reporting engine and even more WYSIWYG editor of reports and templates. NB has an advantage here as well, Jasper Reports is probably the most widely used Java-based reporting tool and there is a visual designer integrated into NB called Jarvis, but according to the page there has been no development since 6.0.
    Comment by AntonEpple: Development of Jarvis was stopped, because NetBeans now has the iReport plugin ( I'm the original developer of Jarvis )

Eclipse has BIRT, which has been improved a lot in Ganymede release. A commercial Report Editor for End Users is available for it.

TBD if above stated points are agreed upon and something should be done with them. Here is a list of possible suggestions.

Suggestions

  • Ant-based projects - easy headless build is IMO a big advantage of NB Platform and everybody developing real-world application needs it, I'd suggest adding a chapter to application tutorials.
  • XML layers:
  • As META-INF/services don't do anything that XML layers couldn't do as well, my suggestion would be to mark it as obsolete technique in documentation and to slowly move towards using XML layers only.
  • If possible, allow modules to claim "ownership" of folders in XML layer, provide editing and validation schema and documentation for the nodes.
  • Visual editing of application UI - <This layer in context> node in project window does a lot of the job, but can be taken further with visual editors of main menu, toolbars and window layout. The editor would display UI according to suite configuration (enabled modules) and allowed:
  • adding actions and windows to modules at appropriate places
  • renaming, rearranging and hiding of actions and windows (TODO - link issue)
  • Application configuration:
  • Allow user modules to form suites or clusters which can be used by multiple applications
  • Allow for compile-on-save for NB modules
  • Provide better support configuration of modules enabled in the application (at least recursive Enable required modules and Disable modules with unsatisfied dependiencies actions in Project Properties / Libraries) (issue #122821)
  • Provide empty application configuration. TODO - already possible?
  • We should be able to declare NetBeans IDE application in the same terms that are available for platform applications.

TBD if the suggestions are doable and how.


Other (subjective) strong points of the IDEs

TODO - some comments to the points

NetBeans

  • Matisse GUI Builder
  • Profiler
  • Macros
  • Integration of tools - mobility, identity management (...)

Eclipse

Could be better in both

  • Debugger - NB debugger being better of the two, Visual Studio debugger still has the best one

My Favorite Post 6.5 Enhancements list

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