Friday Nov 14, 2008

New Feature in NetBeans 7.0 - Plugin Importer

As you know, NetBeans 6.5 coming.... and contributing new features into NetBeans 7.0 (Dev) has started recently. One of them - importing plugins from previous release into new one - is here.

How does Plugin Import work?

  • If are you starting NetBeans 7.0 (Dev) for the first time e.g. with fresh userdir, you will be asked if you want to import settings from previous version (if any). Let's say Yes.
  • NetBeans imported your settings and then continue starting of IDE as usual.
  • After some delay, Plugin Import will investigate the previous version - the previous userdir - for NetBeans plugins placed there.
  • If any plugins found there:
    1. Plugin Import check if these plugins are installed already in running IDE.
    2. Plugin Import checks if these plugins are available on any subscribed Update Center in Tools|Plugins
    3. If none of that, Plugin Import investigates if these plugins could be copied into running IDE.
  • In case that some plugins can import, you will be notified by icon  in IDE status line, clicking on it you can invoked the dialog above.

So if you found any problems your feedback is more then welcomed. Either file a issue into Issuezilla (choose autoupdate category) or let me know here. Thanks

Design and UI outline is at

Q: There is a possibility to import plugins from different directory?

  • Yes, there is. Just run you NetBeans application (IDE) with command line switch -J-Dplugin.manager.import.from=/path/to/cluster
  • You need to specify path to any NetBeans userdir or whatever NetBeans cluster.

In the end, a small org announcement :-) Further developing or maintaining of Plugin Manager/Autoupdate Services have been overtaken by a team who cares for NetBeans IDE installation for whole and I'm going to support NetBeans Plugin Development aka apisupport. Thank you for your feedback and reporting problems you found in Plugin Manager which helping us to deliver Plugin Manager in a fair quality.

Thursday Sep 11, 2008

Problems with installing plugins on Windows Vista? No longer in NetBeans 6.5

Have you ever seen Access denied on Windows Vista while installing new plugins? It could happen on Vista in some certain cases in Plugin Manager.

Several issues have been fixed recently in NetBeans 6.5 in this area. Some of them caused by known (but very ugly behavior) problem directory.canWrite() could returns true (when directory is a even thought the directory is read only. As workaround I try to open to make sure if I can write them or not. Further, write permission should be checked not only on cluster directories, but also on subdirectories which can be owned by another user (namely the user Administrator if NetBeans are run in Vista admin mode sometime).

Other set of problems were caused by open file handlers in NetBeans launcher. Although there directories were hold, directory.delete() returns true as directory was successfully deleted, but it was not true, the directory left there. Then Java cannot open this one, write into nor use it anymore, it always ends Access denied until NetBeans was running.

For your information, there are such issues:

and maybe some more recently fixed in this area.

If you want to try nightly builds on NetBeans 6.5 on  and please send your feedback about this upcoming NetBeans release. Thanks

Wednesday Aug 27, 2008

Yet another significant speed up the Plugins Manager

As I was writing in my previous post I've continued on improving performance of Plugin Manager. After lowering memory consumption while parsing content of Update Centers I'm focusing speed of handling plugin's updates. I got feedback several times that install of the patches of NetBeans 6.1 IDE can be very slow, specially when installing a big patch into full IDE distribution. I that case IDE users have to sit by and be watching Please wait dialog for a few minutes.................... It was ugly :-(

It was really ugly but it won't be anymore. I achieved significant acceleration of processing plugin's updates. Thanksgiving Jara now I have a testing Update Center containing updates of all plugin's installed in Development build of NetBeans IDE. With that UC I investigated and measured processing update in Plugin Manager. I found out some methods has to be called million times. Although it made sense in the applied analysis model of plugins dependencies, model computation was inacceptable due to its slowness. So, that's the right momentum to start thinking about change the model. Right, I had to do it.

The former model works over plugin-to-plugin dependencies. Starting with some visible plugin goes down to else plugins on which depending on. If some of evaluated dependencies forced to add plugin within collection of updates, the dependencies evaluation will continue on itself and so on. It worked, but some dependency evaluation can become useless. If the case P1 depends on D and P2 depends on D as well, analysis model contains dependency P1->D and P2->D, it means two evaluations.

The new model does abstraction which plugin depends on another one and just evaluates dependency itself regardless which plugin declaring that on. In the previous example, the new analysis model works with ?->D dependency only, it means only once evaluation instead of twice. Just idea but with amazing consequence, on testing Update Center is much faster from 40s on old model to 2s (!!!) on the new one. In the Big O notation words, the former model was working with O(n2) but the new model has O(n) complexity I think.

Simply, fixing performance problems can be a amazing story sometime. I'm sure this algorithm change makes Plugin Manager better with much better impression while installing future patches into NetBeans 6.5. The new algorithm in Plugin Manager has been integrated just now, so in the daily development builds should be in a few days.

Just try it....

Tuesday Aug 12, 2008

Bye, Bye, DOM parser in Plugin Manager

NetBeans teams are in fixing and stabilization phase of upcoming release NetBeans 6.5. The modules Autoupdate (API) and Plugin Manager (UI) are in step of fixing as well. After most of functional bugs have been fixed in previous milestones of NetBeans, I'm targeting the performance area in these modules.

One of most reporting problems is a high memory consumption while parsing content of Update Centers. Because usually content of Update Center is represented in XML structure, Plugin Manager used DocumentBuilder to get DOM document and processing DOM Nodes. This way was easy and elegant but due to having many many modules in NetBeans codebase which made XML file too big, creating and processing that Document consumption too big memory, commonly 60-70MB on memory heap. Even though such big memory is allocated temporary and will return back to JVM, it could cause OutOfMemoryException sometimes.

Since NetBeans 6.5 (but not in NetBeans 6.5 Beta!) Autoupdate/Plugin Manager don't use DOM document for processing such XML files, uses SAX parser which is lighter and asks less memory to handling XML elements. By my memory measuring the Plugin Manager the memory consumption decreased to 30MB on the heap, it means 50-60%. It's not bad although it might have been better :-)

Stay tuned, more performance improvements have been integrated in NetBeans 6.5 Beta (coming soon) and some else are planning for fixing phase of NetBeans 6.5 after beta too.

Friday May 09, 2008

A few words about my BOF

Wednesday. The seventh of May. I attended couple of sessions and except that I was hearing the presentation matter I was watching speakers: theirs opening of session, how to do demonstration on the stage, how to recover if something went wrong and so on. I must say it made me calm down. Speakers as well as attendees take everything at ease, didn't worries anyhow. So, it was good message for me :-)


Geertjan and me did the last tuning of laptops for our demonstration, guys from Moscone setup mikes for us and all went good, we just were waiting on the stage when the first attendees came .... and our show started.

I dare to say the BOF went good, all demos were working (with a irrelevant exception), attendees didn't go away (with minor exceptions as well) and many of them looked like be interested in the matter of this BOF. Actually, we had to stop Questions/Answers because our time was out. However we weren't be faced to standing ovation :-) the applause sounded very good, anyway.

Just was a pity no NetBeans Platform guys came early to take some pictures. Maybe next time :-)

In the end I would like to say big THANKS to Geertjan for his support while preparing our talk.

Monday Mar 17, 2008

Missing Modules Resolver (part II)

For those who are interested in implementation of Missing Modules Resolver I can show some implementation details.

The Missing Modules Resolver is built on the top of Autoupdate API and uses several Autoupdate services for find out broken modules, download&install missing modules to match its dependencies and enable them again in the end. Rest of implementation is just UI.

Okay, let's see the utilized services and look at code snippets.

Find out broken modules

Entry point into Autoupdate API is the
UpdateManager.getDefault ()
what providers set of units which can be browsed in UI and perform operations on them (i.e. install, update or unistall etc.) Each UpdateUnit represents a NetBeans module either as installed in IDE or available on Update Center. If a module is already installed but also has available higher version in any Update Center, the module has update one.
Now, we need find out modules what are already installed but aren't enabled in IDE.
Collection<UpdateUnit> units = UpdateManager.getDefault().getUpdateUnits(UpdateManager.TYPE.MODULE);
for (UpdateUnit unit : allUnits) {
if (unit.getInstalled() != null && ! unit.getInstalled().isEnabled()) {
res.add (unit.getInstalled());
Great, we have installed but disabled modules but how to diagnose the module is broken and cannot be enabled? Ask them why cannot be enable, i.e. get its broken dependencies. If there are some broken we have a candidate for resolving.
OperationContainer<operationsupport> forEnable = OperationContainer.createForEnable (); // take support for enabling modules
OperationContainer.OperationInfo<operationsupport> info = forEnable.add([installed-but-disabled-module]);
Set<string> broken = info.getBrokenDependencies(); // ask for broken dependencies
if (! broken.isEmpty()) { // if are some => we have the candidate
candidate.put(el, broken);

So, now we have all candidate for resolving its problems.

Look for missing modules

Now let's look for missing modules. Each candidate knows own broken dependencies. These dependencies are the clue for us to search out set of missing module which can fix these dependencies. There is a sample how to get it:

Collection<UpdateElement> missingModules = ...
OperationContainer.OperationInfo<operationsupport> info = forEnable.add([installed-but-disabled-module]);
Set<UpdateElement> reqs = new HashSet<UpdateElement>(info.getRequiredElements()); // add required modules

Great, we found out a collection of missing modules what are required by other modules in IDE. We should install them.


Take the operation container for install operation, put all missing modules into this container what can perform all action for install them: download, validate, install and restart IDE if needed.

OperationContainer<InstallSupport> forInstall = OperationContainer.createForInstall(); // take the install container
forInstall.add(missing-modules); // put all missing modules
InstallSupport installSupport = installContainer.getSupport(); // take the install support what is executive for actions above
ProgressHandle progress = ... // ProgressHandle
Validator v = installSupport.doDownload(progress); // perform download
Installer i = installSupport.doValidate(v, progress); // perform validation
Restarter r = installSupport.doInstall(i, progress); // perform install
if (r != null) { // need restart?
installSupport.doRestart(r, progress);

Enabled broken modules again

It's easy, just let's take a operation container for enabling modules, put all broken module and invoke enable action. All module should be able to turn on again.
OperationContainer<OperationSupport> forEnable = OperationContainer.createForEnable (); // take support for enabling modules
forEnable.add(candiates); // put all candidates
OperationSupport enableSupport = enableContainer.getSupport(); // take the enable support
ProgressHandle progress = ... // ProgressHandle enableSupport.doOperation(progress);

That's all :-)

Who would like to see all sources or contribute some improvements or fix bugs, go into contrib repository at The NetBeans project takes name moduleresolver.
Bugs or RFE report into IssueZilla against component contrib and owner Thanks for your feedback.




« July 2016