Wednesday May 26, 2010

Silent Update of RCP Application as NetBeans Module Sample

I got many requests to showing how to update Netbeans RCP Application silently. I blogged about long time ago - how_to_update_netbeans_platform including some code snippets. Right now I published on a NetBeans Module Sample Sample Silent Update which allows you to add a sample doing Silent Update directly to your application.

How to try it?

[Read More]

Friday Jan 23, 2009

Quietly disable modules at runtime?

I was given a inquiry from user of NetBeans Platform. He want to know a way how to disable one or more modules in running application built on NetBeans Platform, in additional it must be perform silently, i.e. with no end-user intervention or any assistance.

Well, he requirement is clear but its fulfillment has several difficulties: first, modules in NetBeans Platform depends on each other and it's uneasy to discover modules which don't involve any essential module of platform. Second, modules can depend on each other even thought don't declare such dependency. Such ad-hoc dependencies are mistakes and NetBeans architecture is aiming to avoid them but few of them can still left there. This fact leaded NetBeans team to do disabling of module only in "offline" time, it means when NetBeans application is not running currently.

Okay. It was bad news, good news is that Autoupdate Services API has capability to perform disabling of module in currently running application (with awareness of possible problems stated above).

[Read More]

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.

Tuesday Jun 03, 2008

How do you like balloon-like tooltip?

NetBeans IDE regularly checks for available updates of your IDE's installed plugins. Since NetBeans 6.0 IDE the NetBeans team delivering patches almost monthly and it makes alerting users about new updates more important than ever.

On this account Stan introduced balloon-like tooltip in NetBeans 6.1 IDE. The balloon will notify IDE users about available updates in the IDE status line if some updates found. Like this

The balloon is showing for 30 seconds when Plugin Manager found available updates. Or an user can invoke it like tooltip on mouse over the update icon .

Some users (most of IDE users I believe) like this balloon and some don't. I got some feedback on NetBeans 6.1 IDE and did a little change for NetBeans 6.5 IDE:

  • balloon acts more as tooltip. If it shows on mouse event, it will close quickly on mouse exit.
  • balloon is showing only when Plugin Manager connects Update Centers and not while working over caches
  • power users can customize appearance of balloon by new options: FaqPluginManagerCustomization
  • beside this Stan have also changed UI of balloon a bit.

What about you? How do you like the balloon stuff? Thank you for feedback

Friday May 09, 2008

JavaOne 2008 is over!

As quickly as JavaOne 2008 was opened it was over.

I saw a couple of interesting sessions or BOFs, some of them were amazing, a few a little boring and I think it was good stuff. I can meet many of NetBeans platform users which the best one benefit such congresses.

Among other things, a lot amazing parties belong to JavaOne as well as technical sessions. In the end, the After Dark party with some Rock music on the stage. However it was over over very quickly too :-(

[Read More]

Thursday Apr 10, 2008

Stop by at JavaOne's BOF: Consumer IDE

Are you attending JavaOne 2008? Geertjan Wielenga and I will be giving BOF
Toward a Consumer IDE: Get What You Want When You Want It. Come and see it on Wednesday May 7th 2008, it's starting 6:30 PM. You are highly welcome there.

Our Birds-on-a-Feather (BOF) Consumer IDE introduces a new approach. Provide a high-personalized distribution for users and allow users to customize the application on-the-fly and get exactly what they want to have. We show several demos of this functionality and then make a tutorial how to design application using that concept: a draft of API and code snippets are inclusive :-) Stop by...

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.




« April 2014