'. '

Netbinox

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(The Differences between Netbinox and Equinox)
Current revision (11:18, 16 April 2012) (edit) (undo)
 
(34 intermediate revisions not shown.)
Line 1: Line 1:
-
Interested in [[Swing]] and [[Equinox]]? Then welcome to the world where these systems co-exist in peace! [[Netbinox]] is a synergy between [[NetBeans Platform]] and [[Equinox]]. With recent improvements to [[NetbinoxPerformance]], this project now represents the fastest [[OSGi]] container on the planet. Even faster than plain [[Equinox]].
+
[[Netbinox]] just had its ''Experiences from Building the Fastest OSGi Container on the Planet'' at [[OSGiCon]]. Find the slides at the dedicated [[OSGiCon|page]]. Listen to our [[API Design Tips|podcast]]: [[Image:APITip-OSGiCon.mp3]].
 +
 
 +
 
 +
[[Netbinox]] is a synergy between [[NetBeans Platform]] and [[Equinox]]. With recent improvements to [[NetbinoxPerformance]], this project now represents the fastest [[OSGi]] container on the planet. Even faster than plain [[Equinox]].
 +
 
 +
Since [[NetBeans]] 7.1 the [[Netbinox]] is used by the [[NetBeans]] IDE to host parts of [[Mylyn]] (especially [[bugzilla]] and [[JIRA]] connectors).
== Can [[Netbinox]] be Better than [[Equinox]]? ==
== Can [[Netbinox]] be Better than [[Equinox]]? ==
Line 5: Line 10:
How can something bigger be faster than something smaller? That is one question that I was asked recently. Yeah, sounds a little unnatural. However it is still a real question. Still in doubt? Well, in the 18th century, people believed that ''things heavier than air can't fly'' too.
How can something bigger be faster than something smaller? That is one question that I was asked recently. Yeah, sounds a little unnatural. However it is still a real question. Still in doubt? Well, in the 18th century, people believed that ''things heavier than air can't fly'' too.
-
The beauty of the [[Netbinox]] solution lies in the joining of efforts. The [[NetBeans]] team is a long term expert in improving [[Startup]] [[performance]]. We managed to reduce startup time of [[NetBeans]] by 60% since release 6.1. We have the know-how [[modularity|modular]] desktop applications need to start as quickly as possible. The [[Netbinox]] project transfers that knowledge to the [[Equinox]] world. As a result, by joining our forces, we managed to significantly improve the cold [[startup]] time of large [[OSGi]] packaged [[Swing]] based applications (without changing code), as the following table shows:
+
The beauty of the [[Netbinox]] solution lies in the joining of efforts. The [[NetBeans]] team is a long term expert in improving [[Startup]] [[performance]]. We managed to reduce startup time of [[NetBeans]] by 60% since release 6.1. We have the know-how [[modularity|modular]] desktop applications need to start as quickly as possible. The [[Netbinox]] project transfers that knowledge to the [[Equinox]] world. As a result, by joining our forces, we managed to significantly improve the cold [[startup]] time of [[JDeveloper]] (e.g. large [[OSGi]] packaged [[Swing]] based application) without changing a line of its code, as the following table shows:
{| border="1"
{| border="1"
Line 22: Line 27:
|}
|}
-
Despite [[Netbinox]] being bigger than [[Equinox]] (naturally), it delivers a faster ''daily morning'' [[startup]]. This is the result of applying the [[netbeans:StartupCache|best practices]] we learned while developing [[NetBeans]] and [[Bridge|bridging]] them for [[OSGi]] users. [[Netbinox]] is now the fastest desktop application [[OSGi]] container on earth.
+
Despite [[Netbinox]] being bigger than [[Equinox]] (naturally), it delivers a faster ''daily morning'' [[startup]]. This is the result of applying the [[netbeans:StartupCache|best practices]] we learned while developing [[NetBeans]] and [[Bridge|bridging]] them for [[OSGi]] users. [[Netbinox]] is now the fastest desktop application [[OSGi]] container on the Earth.
== The Differences ==
== The Differences ==
-
The goal of this project is to make sure that bundles running inside of the [[OSGi]] container see the exact execution [[environment]] as they are used to. In case you have a bundle and you are calling into the [[OSGi]] [[API]]s and you see some difference, don't hesitate to [https://netbeans.org/bugzilla/enter_bug.cgi?product=platform&component=Netigso report a bug].
+
The goal of the [[Netbinox]] project is to make sure that bundles running inside of the [[OSGi]] container see the exact execution [[environment]] as they are used to. In case you have a bundle and you are calling into the [[OSGi]] [[API]]s and you see some difference, don't hesitate to [https://netbeans.org/bugzilla/enter_bug.cgi?product=platform&component=Netigso report a bug].
 +
 
 +
The [[Netbinox]] system reconfigures classical [[Equinox]] container and replaces its bundle content access system. Instead of classical (and slow) ''ZipBundleFile'', there is enhanced [http://hg.netbeans.org/main-golden/file/28b6c82b5f81/netbinox/src/org/netbeans/modules/netbinox/JarBundleFile.java JarBundleFile] which knows how to communicate with [[NetBeans Runtime Container]] [[netbeans:StartupCache|start caches]]. This is the heart of the whole system that brings the [[performance]] improvements and makes the ''difference''. I write ''difference'' in both, positive and negative meaning. As the whole bundle access system is rewritten, there is non zero probability its behaviour is not [[Amoeba|completely same]] as the original one (see the previous paragraph what to do if you find a difference).
 +
 
 +
The deviations observable from within the [[OSGi]] specification shall be limited to those related to bundle content access. However, there may be other type of deviations, as the [[OSGi]] specification does not prescribe the installation layout neither specific [[OSGi]] container extensions, nor it defines behavior of [[ThreadContextClassLoader]]. [[Equinox]] also provides its own extension [[NetbinoxHook|hooks]], not part of [[OSGi]] specification. [[NetbinoxHook]]s are as similar as possible, but are registered in slightly different [[NetbinoxHook|way]].
 +
 
 +
The [[Netbinox]] system wraps the [[Equinox]] container and takes care of loading its classes. In order to support not just [[Equinox]], but also [[Felix]] (as part of [[Netigso]] project), we had to separate the [[OSGi]] [[API]] classes from the [[JAR]]s of those [[OSGi]] containers. Since version 1.16.8 the ''modules/ext/equinox.jar'' used by [[Netbinox]] is identical to up stream ''org.eclipse.osgi_VERSION.vDATE.jar'' (it used to contain only [[Equinox]] specific classes before [https://netbeans.org/bugzilla/show_bug.cgi?id=195305 195305] was fixed). The common [[OSGi]] [[API]]s are in ''modules/ext/osgi.cmpn-4.2.jar'' and ''modules/ext/osgi.core-4.2.jar''. No problems related to this separation were reported so far.
 +
 
 +
While using [[Equinox]] in the [[Eclipse]] way, one gets not only the [[OSGi]] container, but often also reuses the launcher. This launcher has some assumptions about configuration files, command line options, etc. None of this is reused by [[Netbinox]]. Rather the configuration files are standard [[NetBeans]] ones (although there are ways to read [[Eclipse]] like ones too). The [[Eclipse]] like command line options are not recognized, however most of the functionality remains accessible via system properties. For example, one cannot use ''-console'' to start the [[Equinox]]'s [[OSGi]] console, but one can still specify ''-J-Dosgi.console='' property to turn the same functionality on. There are ways to enhance the [[NetBeans]] and thus [[Netbinox]] launcher to understand new options, however that is a topic for another document.
 +
 
 +
The goal of [[Netbinox]] is to be fully compatible with [[Equinox]] from inside the [[OSGi]] container. The goal is not to mimic how the container looks and is accessed from outside. By default the standard [[NetBeans]] like access is supported, although there are ways to mimic the [[Eclipse]] like approach too.
-
The [[Netbinox]] system reconfigures classical [[Equinox]] container and replaces its bundle content access system. Instead of classical (and slow) ''ZipBundleFile'', there is enhanced ''JarBundleFile'' which knows how to communicate with [[NetBeans Runtime Container]] [[netbeans:StartupCache|start caches]]. This is the heart of the whole system that brings the [[performance]] improvements and makes the ''difference''. I write ''difference'' in both, positive and negative meaning. As the whole bundle access system is rewritten, there is non zero probability its behaviour is not completely same as the original one (see the previous paragraph what to do if you find a difference).
+
== Try [[Netbinox]]! ==
-
The previous differences was observable from within the [[OSGi]] specification. The remaining ones are not, as [[OSGi]] specification does not deal with installation layout neither with specific container extensions.
+
Prior to [[NetBeans]] 7.1 the [[Netbinox]] was a separate component (see [[NetbinoxTutorial]]). Since [[NetBeans]] 7.1. it is an integral part of the [[NetBeans]] [[IDE]] used to host parts of [[Mylyn]] infrastructure running in the system.
-
The [[Netbinox]] system wraps the [[Equinox]] container and takes care of loading its classes. In order to support not just [[Equinox]], but also [[Felix]] (as part of [[Netigso]] project), we had to separate the [[OSGi]] [[API]] classes from the [[JAR]]s of those [[OSGi]] containers. As a result the ''modules/ext/equinox.jar'' used by [[Netigso]] is not identical to up stream ''equinox.jar''. Rather it contains only [[Equinox]] specific classes. The common [[OSGi]] [[API]]s are in ''modules/ext/osgi.cmpn-4.2.jar'' and ''modules/ext/osgi.core-4.2.jar''. No problems related to this separation were reported so far.
+
The easiest way to try [[Netbinox]] is to create sample application delivered with [[NetBeans]] IDE:
-
While using [[Equinox]] in the Eclipse way, one gets not only the [[OSGi]] container, but often also reuses the launcher. This launcher has some assumptions about configuration files, command line options, etc. None of this is reused by [[Netbinox]]. Rather the configuration files are standard [[NetBeans]] ones (although there are ways to read classical ones too). The Eclipse like command line options are not recognized, however most of the functionality remains accessible via system properties. For example, one cannot use ''-console'' to start the [[Equinox]]'s [[OSGi]] console, but one has to use ''-J-Dosgi.console=''. There are ways to enhance the [[NetBeans]] and thus [[Netbinox]] launcher to understand the new options, however that is a topic for another document.
+
[[Image:NetbinoxSample.png]]
-
The goal of [[Netbinox]] is to be fully compatible with [[Equinox]] from inside the [[OSGi]] container. The goal is not to mimic how the container looks and is accessed from outside. By default the standard [[NetBeans]] like access is supported, although there are ways to mimic the Eclipse like approach too.
+
Just finish the wizard and run the project. A sample application showing all OSGi bundles available in the system (including [[NetBeans]] Platform [[API]]s) will be shown.
-
== The [[NetbinoxTutorial]] ==
+
In case you feel lazier, you can listen and watch me and [[Geertjan]] demonstrating and discussing the power of [[Mylyn]], [[NetBeans]] and the [[module system|common ground]] in the following screen cast:
-
{{:NetbinoxTutorial}}
+
{{#ev:bliptv|2790848}}
== Resources ==
== Resources ==
 +
* List of [http://netbeans.org/bugzilla/buglist.cgi?query_format=advanced&product=platform&component=Netigso&bug_status=NEW&bug_status=STARTED&bug_status=REOPENED bugs] - report [https://netbeans.org/bugzilla/enter_bug.cgi?product=platform&component=Netigso new bug]!
* [http://lists.apidesign.org/mailman/listinfo/netigso mailing list] - subscribe, view archives, etc.
* [http://lists.apidesign.org/mailman/listinfo/netigso mailing list] - subscribe, view archives, etc.
-
* [http://source.apidesign.org/hg/netbinox Repository] with [[GPL]]ed sources
+
* [http://hg.netbeans.org/main-golden/file/6d6ad73f5bcb/netbinox sources] inside [[NetBeans]] [[Mercurial]] repository (dual licensed under [[CDDL]] or [[GPLwithClassPathException]])
-
* [http://hudson.apidesign.org/job/netbinox Builds] made daily
+
:* Old [http://source.apidesign.org/hg/netbinox Repository] with [[GPL]]ed sources
-
* [[Netigso|General Overview]]
+
* Download [[NetBeans]] Java SE 7.1 or newer from [http://netbeans.org/ netbeans.org]
 +
* History of alignment of [[Netigso|OSGi and NetBeans]]
 +
* Presentation at [[OSGiCon]] 2012 with [[OSGiCon|slides]]
-
== Why [[GPL]]? ==
+
== [[Netbinox]] is Free! ==
-
The [[Netbinox]] project is primarily licensed under [[GPL]]. This is for your own good, as it ensures this project is supported by all its users. However you can of course, avoid the [[GPL]] viral restrictions. There are two options:
+
Originally I licensed the [[Netbinox]] project under [[GPL]]. This payed off, as I knew (most of) my customers. Almost everyone who wanted to use the [[Netbinox]] needed to send me an email and ask. Either to verify usage of [[GPL]] is OK, or to ask for a different license. Only due to viral nature of [[GPL]] I was [[Talk:NetbinoxPerformance|contacted]] by members of the [[Equinox]] team to find out whether I want to donate the [[NetbinoxPerformance]] to [[Equinox]].
-
First of all you may find out that you do not need [[Equinox]], that compliant [[OSGi]] container is enough. In such case, please use [[Netigso]] project which incorporates [[Apache]]'s [[Felix]] and does that without the [[GPL]] ''virality'' using the standard [[NetBeans]] license.
+
However since [[Netbinox]] is now used by [[JDeveloper]] and is also used by the [[Mylyn]] modules inside [[NetBeans]] 7.1, it does not make sense to keep it under [[GPL]]. It is more natural to give it the classical, liberal open source [[NetBeans]] license ([[CDDL]] or [[GPLwithClassPathException]]). Since [[NetBeans]] 7.1 you can use [[Netbinox]] together with [[NetBeans]] Platform without any licensing limitations.
-
In case you really need [[Equinox]], you have the option is to license the [[Netbinox]] project under non-[[GPL]] license. Please write to [mailto:licensing@apidesign.org licensing@apidesign.org] to learn details.
+
I will loose track of those who use [[Netbinox]], but I hope to see more and more [[Netbinox]] based applications for real. Because: why would you use [[Equinox]] when [[Netbinox]] is fully [[Netbinox#The_Differences|compatible]] and much [[NetbinoxPerformance|faster]]?
<comments/>
<comments/>

Current revision

Netbinox just had its Experiences from Building the Fastest OSGi Container on the Planet at OSGiCon. Find the slides at the dedicated page. Listen to our podcast: . Netbinox is a synergy between NetBeans Platform and Equinox. With recent improvements to NetbinoxPerformance, this project now represents the fastest OSGi container on the planet. Even faster than plain Equinox. Since NetBeans 7.1 the Netbinox is used by the NetBeans IDE to host parts of Mylyn (especially bugzilla and JIRA connectors).

Contents

Can Netbinox be Better than Equinox?

How can something bigger be faster than something smaller? That is one question that I was asked recently. Yeah, sounds a little unnatural. However it is still a real question. Still in doubt? Well, in the 18th century, people believed that things heavier than air can't fly too.

The beauty of the Netbinox solution lies in the joining of efforts. The NetBeans team is a long term expert in improving Startup performance. We managed to reduce startup time of NetBeans by 60% since release 6.1. We have the know-how modular desktop applications need to start as quickly as possible. The Netbinox project transfers that knowledge to the Equinox world. As a result, by joining our forces, we managed to significantly improve the cold startup time of JDeveloper (e.g. large OSGi packaged Swing based application) without changing a line of its code, as the following table shows:

type of Startup Netbinox Equinox
cold 37s 1m 2s
warm 8s 9s

Despite Netbinox being bigger than Equinox (naturally), it delivers a faster daily morning startup. This is the result of applying the best practices we learned while developing NetBeans and bridging them for OSGi users. Netbinox is now the fastest desktop application OSGi container on the Earth.

The Differences

The goal of the Netbinox project is to make sure that bundles running inside of the OSGi container see the exact execution environment as they are used to. In case you have a bundle and you are calling into the OSGi APIs and you see some difference, don't hesitate to report a bug.

The Netbinox system reconfigures classical Equinox container and replaces its bundle content access system. Instead of classical (and slow) ZipBundleFile, there is enhanced JarBundleFile which knows how to communicate with NetBeans Runtime Container start caches. This is the heart of the whole system that brings the performance improvements and makes the difference. I write difference in both, positive and negative meaning. As the whole bundle access system is rewritten, there is non zero probability its behaviour is not completely same as the original one (see the previous paragraph what to do if you find a difference).

The deviations observable from within the OSGi specification shall be limited to those related to bundle content access. However, there may be other type of deviations, as the OSGi specification does not prescribe the installation layout neither specific OSGi container extensions, nor it defines behavior of ThreadContextClassLoader. Equinox also provides its own extension hooks, not part of OSGi specification. NetbinoxHooks are as similar as possible, but are registered in slightly different way.

The Netbinox system wraps the Equinox container and takes care of loading its classes. In order to support not just Equinox, but also Felix (as part of Netigso project), we had to separate the OSGi API classes from the JARs of those OSGi containers. Since version 1.16.8 the modules/ext/equinox.jar used by Netbinox is identical to up stream org.eclipse.osgi_VERSION.vDATE.jar (it used to contain only Equinox specific classes before 195305 was fixed). The common OSGi APIs are in modules/ext/osgi.cmpn-4.2.jar and modules/ext/osgi.core-4.2.jar. No problems related to this separation were reported so far.

While using Equinox in the Eclipse way, one gets not only the OSGi container, but often also reuses the launcher. This launcher has some assumptions about configuration files, command line options, etc. None of this is reused by Netbinox. Rather the configuration files are standard NetBeans ones (although there are ways to read Eclipse like ones too). The Eclipse like command line options are not recognized, however most of the functionality remains accessible via system properties. For example, one cannot use -console to start the Equinox's OSGi console, but one can still specify -J-Dosgi.console= property to turn the same functionality on. There are ways to enhance the NetBeans and thus Netbinox launcher to understand new options, however that is a topic for another document.

The goal of Netbinox is to be fully compatible with Equinox from inside the OSGi container. The goal is not to mimic how the container looks and is accessed from outside. By default the standard NetBeans like access is supported, although there are ways to mimic the Eclipse like approach too.

Try Netbinox!

Prior to NetBeans 7.1 the Netbinox was a separate component (see NetbinoxTutorial). Since NetBeans 7.1. it is an integral part of the NetBeans IDE used to host parts of Mylyn infrastructure running in the system.

The easiest way to try Netbinox is to create sample application delivered with NetBeans IDE:

Image:NetbinoxSample.png

Just finish the wizard and run the project. A sample application showing all OSGi bundles available in the system (including NetBeans Platform APIs) will be shown.

In case you feel lazier, you can listen and watch me and Geertjan demonstrating and discussing the power of Mylyn, NetBeans and the common ground in the following screen cast:

Resources

Netbinox is Free!

Originally I licensed the Netbinox project under GPL. This payed off, as I knew (most of) my customers. Almost everyone who wanted to use the Netbinox needed to send me an email and ask. Either to verify usage of GPL is OK, or to ask for a different license. Only due to viral nature of GPL I was contacted by members of the Equinox team to find out whether I want to donate the NetbinoxPerformance to Equinox.

However since Netbinox is now used by JDeveloper and is also used by the Mylyn modules inside NetBeans 7.1, it does not make sense to keep it under GPL. It is more natural to give it the classical, liberal open source NetBeans license (CDDL or GPLwithClassPathException). Since NetBeans 7.1 you can use Netbinox together with NetBeans Platform without any licensing limitations.

I will loose track of those who use Netbinox, but I hope to see more and more Netbinox based applications for real. Because: why would you use Equinox when Netbinox is fully compatible and much faster?

Name (required):

Comment:

Personal tools