'. '

JDeveloper

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Sharing)
(Meanwhile on the Other Side of the Ocean)
Line 15: Line 15:
=== Meanwhile on the Other Side of the Ocean ===
=== Meanwhile on the Other Side of the Ocean ===
-
[[JDeveloper]] is rich platform. As rich as [[NetBeans Platform]] and in some sense even richer. As such I was not even trying to suggest [[JDeveloper]] guys to adopt purely [[NetBeans]] solutions. Rather I hoped we could both agree on some standard. [[OSGi]] seemed like a good candidate (for some distant future). You would not believe how surprised I was when I found out (during first visit of [[Oracle]] guys to Prague in April 2010) that they have already rewrote [[JDeveloper]] to run on top of [[OSGi]] (thanks Stoyan for all the work!). I was surprised, but pleased, as this validated our decision to support [[OSGi]] in the 6.9 release!
+
[[JDeveloper]] is rich platform. As rich as [[NetBeans Platform]] and in some sense even richer. As such I was not even trying to suggest [[JDeveloper]] guys to adopt purely [[NetBeans]] solutions. Rather I hoped we could both agree on some standard. [[OSGi]] seemed like a good candidate (for some distant future). You would not believe how surprised I was when I found out (during first visit of [[Oracle]] guys to Prague in April 2010) that they had already rewritten [[JDeveloper]] to run on top of [[OSGi]] (thanks Stoyan for all the work!). I was surprised, but pleased, as this validated our decision to support [[OSGi]] in the 6.9 release!
<!--
<!--

Revision as of 10:32, 13 June 2011

JDeveloper is the primary IDE for support of Oracle non-open source technologies (like ADF). I really like JDeveloper's support for working with XML, it is much better than the one we offer in NetBeans.

Contents

Before Acquisition

When we learned that Sun was going to be acquired by Oracle in April 2009 we knew we want to change NetBeans to get ready to be acquired. We started to speculate what could make NetBeans attractive for Oracle. I really mean speculate as up until first quarter of 2011 (when the acquisition was approved by Europian Commission) there was no signals from Oracle to help us understand what way to improve NetBeans. Tough situation. Moreover complicated by the fact that people around were fired every few months and those who stayed had little trust in the future. Still I hoped we will get a chance to prove that NetBeans (and NetBeans Platform) can be useful).

Common Ground

It become clear that the crusial part is going to be our relationship with JDeveloper. No company can sponsor two projects doing almost the same thing in a different way for an unlimited amount of time. We needed to find a way to share. As it is always easier to share when there is a common ground, I started to talk more about OSGi.

I convinced my management and OSGi became main theme for NetBeans 6.9. The Netigso project was a proof of concept demonstrating the whole approach can work. Still there was a lot of things to improve to raise the whole OSGi support to production quality level. In spite of being depresed more and more every day, the NetBeans team worked really hard and I am thankful for that. As a result the NetBeans 6.9 offered OSGi support for every developer. The NetBeans Platform was now built not only on standard UI toolkit, but also de-facto standard module system. Everyone could benefit, but I admit my primary motivation was to met JDeveloper half-way.

Meanwhile on the Other Side of the Ocean

JDeveloper is rich platform. As rich as NetBeans Platform and in some sense even richer. As such I was not even trying to suggest JDeveloper guys to adopt purely NetBeans solutions. Rather I hoped we could both agree on some standard. OSGi seemed like a good candidate (for some distant future). You would not believe how surprised I was when I found out (during first visit of Oracle guys to Prague in April 2010) that they had already rewritten JDeveloper to run on top of OSGi (thanks Stoyan for all the work!). I was surprised, but pleased, as this validated our decision to support OSGi in the 6.9 release!


Performance

We had the common ground I was hoping for (except that we primarily supported Felix and JDeveloper wanted Equinox). Moreover the primary JDeveloper motivation to use OSGi was speed and here I felt we have something more to offer: During work on NetBeans 6.1 we managed to improve startup by 40% using so called CacheForModularity. The only question was how to bring this cache to JDeveloper?

Netbinox already existed (but without using the caches), so it was just a matter of improving it and demonstrating the startup of JDeveloper can improve even more with Netbinox common ground. I worked on that whole summer. Code improvements were relatively easy, but the tough part was to modify the JDeveloper build system to accept NetBeans libraries (thanks Stefan for cross-ocean pair programming). In September we had the results:

JDeveloper running on Equinox (eager mode) Equinox (lazy mode) Netbinox (lazy mode)
Cold startup 1m 58s 1m 2s 37s
Warm caches 13s 9s 8s

The JDeveloper team did quite a good job speeding up JDeveloper by switching to OSGi and implementing so called lazy loading. However even then there was a room for improvement, just by switching to Netbinox, without changing a single line in JDeveloper bundles, cold startup was boosted by another 30%. Warm startup has not been improved, but that one was fast already.

We got an approval to use the technology. Then I spend next few months fixing testing infrastructure to pass nine thousand tests on top of Netbinox. It was not easy and various little differences stayed in a way (one of the most interesting was problem associated with ThreadContextClassLoader). In December 2010, we finally integrated the common ground and the whole product was released in June 2011.

Sharing

TBD: for the team TBD: for JDev users TBD: for NetBeans

Personal tools
buy