Are they both running the same set of bundles (together with some parts of NetBeans)? But in the [[netbinox]] case you have additional extensions to [[Equinox]] that help startup time by doing additional caching?

Are they both running the same set of bundles (together with some parts of NetBeans)? But in the [[netbinox]] case you have additional extensions to [[Equinox]] that help startup time by doing additional caching?

*JT: Right, the same set of bundles. In fact the sample application was [[JDeveloper]]. Large, just modularized application fully independent on [[Eclipse]] or [[NetBeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.

*JT: Right, the same set of bundles. In fact the sample application was [[JDeveloper]]. Large, just modularized (I mean [[OSGi]]fied) application fully independent on [[Eclipse]] or [[NetBeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.

The way you stated "I am glad to report that recently we improved [[Netbinox]] so much that our testing application (together with some parts of [[NetBeans]]) starts faster than [[Equinox]] itself." it sounds as though your whole application starts faster than an empty [[Equinox]] framework. That is not what you meant, correct?

The way you stated "I am glad to report that recently we improved [[Netbinox]] so much that our testing application (together with some parts of [[NetBeans]]) starts faster than [[Equinox]] itself." it sounds as though your whole application starts faster than an empty [[Equinox]] framework. That is not what you meant, correct?

</div>

</div>

Thanks a lot for the advice, I'll give it a try tonight. It really works: [http://hg.netbeans.org/core-main/rev/02f681fc9f3b 02f681fc9f3b]. Thanks. I shall blog about ''improperly documented APIs'' one day - the '''installBundle''' method does not mention this possibility at all. Thus I was seeking for another method like '''installBundleLocally''', I could not imagine the same would be possible with different protocol.

Thanks a lot for the advice, I'll give it a try tonight. It really works: [http://hg.netbeans.org/core-main/rev/02f681fc9f3b 02f681fc9f3b]. Thanks. I shall blog about ''improperly documented APIs'' and [[MagicalStrings]] - the '''installBundle''' method does not mention this possibility at all. Thus I was seeking for another method like '''installBundleLocally''', I could not imagine the same would be possible with different protocol.

--[[User:JaroslavTulach|JaroslavTulach]] 19:50, 3 April 2010 (UTC)

--[[User:JaroslavTulach|JaroslavTulach]] 19:50, 3 April 2010 (UTC)

Are they both running the same set of bundles (together with some parts of NetBeans)? But in the [[netbinox]] case you have additional extensions to [[Equinox]] that help startup time by doing additional caching?

Are they both running the same set of bundles (together with some parts of NetBeans)? But in the [[netbinox]] case you have additional extensions to [[Equinox]] that help startup time by doing additional caching?

*JT: Right, the same set of bundles. In fact the sample application was [[JDeveloper]]. Large, just modularized application fully independent on [[Eclipse]] or [[Netbeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.

*JT: Right, the same set of bundles. In fact the sample application was [[JDeveloper]]. Large, just modularized application fully independent on [[Eclipse]] or [[NetBeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.

The way you stated "I am glad to report that recently we improved [[Netbinox]] so much that our testing application (together with some parts of NetBeans) starts faster than [[Equinox]] itself." it sounds as though your whole application starts faster than an empty [[Equinox]] framework. That is not what you meant, correct?

The way you stated "I am glad to report that recently we improved [[Netbinox]] so much that our testing application (together with some parts of [[NetBeans]]) starts faster than [[Equinox]] itself." it sounds as though your whole application starts faster than an empty [[Equinox]] framework. That is not what you meant, correct?

*JT: Fixed. Thanks.

*JT: Fixed. Thanks.

<div class='commentBlock'>

<div class='commentBlock'>

Could you clarify what is being run in the performance numbers you gave for Equinox vs. Netbinox?

Could you clarify what is being run in the performance numbers you gave for [[Equinox]] vs. [[Netbinox]]?

Are they both running the same set of bundles (together with some parts of NetBeans)? But in the netbinox case you have additional extensions to Equinox that help startup time by doing additional caching?

Are they both running the same set of bundles (together with some parts of NetBeans)? But in the [[netbinox]] case you have additional extensions to [[Equinox]] that help startup time by doing additional caching?

*JT: Right, the same set of bundles. In case of [[Netbinox]] with our own implementation of <code>BundleFile</code>

*JT: Right, the same set of bundles. In fact the sample application was [[JDeveloper]]. Large, just modularized application fully independent on [[Eclipse]] or [[Netbeans]]. Just by replacing [[Equinox]] with [[Netbinox]] and our own implementation of <code>BundleFile</code> reusing [[CacheForModularity]] we managed to speed [[JDeveloper]] up by 30-40%.

The way you stated "I am glad to report that recently we improved Netbinox so much that our testing application (together with some parts of NetBeans) starts faster than Equinox itself." it sounds as though your whole application starts faster than an empty Equinox framework. That is not what you meant, correct?

The way you stated "I am glad to report that recently we improved [[Netbinox]] so much that our testing application (together with some parts of NetBeans) starts faster than [[Equinox]] itself." it sounds as though your whole application starts faster than an empty [[Equinox]] framework. That is not what you meant, correct?

*JT: Fixed. Thanks.

*JT: Fixed. Thanks.

Of course with the ''reference:'' protocol, the [[JAR]]s remain in their original locations and then nobody shall touch them. However (as has been said earlier in this discussion), with ''reference:'' protocol you need to threat the [[JAR]] as being owned by the [[OSGi]] container. No external tool can touch them anyway.

Of course with the ''reference:'' protocol, the [[JAR]]s remain in their original locations and then nobody shall touch them. However (as has been said earlier in this discussion), with ''reference:'' protocol you need to threat the [[JAR]] as being owned by the [[OSGi]] container. No external tool can touch them anyway.

I have a feeling that the [[NetBeans]] ''.lastModified'' solution is on par with the ''reference:'' protocol, plus it defines an external contract to allow command line tools to alter the [[JAR]]s (by touching the ''.lastModified'' file).

I have a feeling that the [[NetBeans]] ''.lastModified'' solution is on par with the ''reference:'' protocol, plus it defines an external contract to allow command line tools to alter the [[JAR]]s (by touching the ''.lastModified'' file). Which is what [[JDeveloper]] does.

--[[User:JaroslavTulach|JaroslavTulach]] 19:44, 8 April 2010 (UTC)

--[[User:JaroslavTulach|JaroslavTulach]] 19:44, 8 April 2010 (UTC)

Of course with the ''reference:'' protocol, the [[JAR]]s remain in their original locations and then nobody shall touch them. However (as has been said earlier in this discussion), with ''reference:'' protocol you need to threat the [[JAR]] as being owned by the [[OSGi]] container. No external tool can touch them anyway.

Of course with the ''reference:'' protocol, the [[JAR]]s remain in their original locations and then nobody shall touch them. However (as has been said earlier in this discussion), with ''reference:'' protocol you need to threat the [[JAR]] as being owned by the [[OSGi]] container. No external tool can touch them anyway.

I have a feeling that the [[NetBeans]] ''.lastModified'' solution is on par with the ''reference:'' protocol, plus it defines an external contract to avoid command line tools to alter the [[JAR]]s (by touching the ''.lastModified'' file).

I have a feeling that the [[NetBeans]] ''.lastModified'' solution is on par with the ''reference:'' protocol, plus it defines an external contract to allow command line tools to alter the [[JAR]]s (by touching the ''.lastModified'' file).

--[[User:JaroslavTulach|JaroslavTulach]] 19:44, 8 April 2010 (UTC)

--[[User:JaroslavTulach|JaroslavTulach]] 19:44, 8 April 2010 (UTC)

--[http://wiki.netbeans.org/JesseGlick Jesse Glick] 18:05, 7 April 2010 (CEST)

--[http://wiki.netbeans.org/JesseGlick Jesse Glick] 18:05, 7 April 2010 (CEST)

</div>

</div>

--[[User:Tjwatson|Tjwatson]] 21:12, 2 April 2010 (CEST)

--[[User:Tjwatson|Tjwatson]] 21:12, 2 April 2010 (CEST)

</div>

</div>

</div>

</div>

Thanks a lot for the advice, I'll give it a try tonight.

Thanks a lot for the advice, I'll give it a try tonight. It really works: [http://hg.netbeans.org/core-main/rev/02f681fc9f3b 02f681fc9f3b]. Thanks. I shall blog about ''improperly documented APIs'' one day - the '''installBundle''' method does not mention this possibility at all. Thus I was seeking for another method like '''installBundleLocally''', I could not imagine the same would be possible with different protocol.

--[[User:JaroslavTulach|JaroslavTulach]] 17:50, 3 April 2010 (UTC)

--[[User:JaroslavTulach|JaroslavTulach]] 19:50, 3 April 2010 (UTC)

== Tjwatson said ... ==

== Tjwatson said ... ==

--Tom Watson 21:01, 2 April 2010 (CEST)

--Tom Watson 21:01, 2 April 2010 (CEST)

</div>

</div>

== Tjwatson said ... ==

== Tjwatson said ... ==

Are they both running the same set of bundles (together with some parts of NetBeans)? But in the netbinox case you have additional extensions to Equinox that help startup time by doing additional caching?

Are they both running the same set of bundles (together with some parts of NetBeans)? But in the netbinox case you have additional extensions to Equinox that help startup time by doing additional caching?

The way you stated "I am glad to report that recently we improved Netbinox so much that our testing application (together with some parts of NetBeans) starts faster than Equinox itself." it sounds as though your whole application starts faster than an empty Equinox framework. That is not what you meant, correct?

The way you stated "I am glad to report that recently we improved Netbinox so much that our testing application (together with some parts of NetBeans) starts faster than Equinox itself." it sounds as though your whole application starts faster than an empty Equinox framework. That is not what you meant, correct?

--[[User:Tjwatson|Tjwatson]] 21:12, 2 April 2010 (CEST)

--[[User:Tjwatson|Tjwatson]] 21:12, 2 April 2010 (CEST)

</div>

</div>

--Tom Watson 21:01, 2 April 2010 (CEST)

--Tom Watson 21:01, 2 April 2010 (CEST)

</div>

</div>