JDeveloper

From APIDesign

Revision as of 08:32, 14 June 2011

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

Before Acquisition

When we learned that Sun would be acquired by Oracle in April 2009 we knew we want to modify NetBeans to be ready for such acquisition. We tried to guess what could make NetBeans attractive for Oracle, but it was almost impossible as up until first quarter of 2010 (when the acquisition was approved by Europian Commission) there was no signals from Oracle to help us understand its NetBeans intentions. 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 would get a chance to prove that NetBeans (and NetBeans Platform) could be useful.

Common Ground

Slowly it became clear that the crucial 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 and modularity in general:

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 level quality. In spite of being depresed more and more every day, the NetBeans team worked hard and I am thankful for that. As a result the NetBeans 6.9 offered OSGi support for every developer. The NetBeans Platform was 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.

Other Side of the Ocean

JDeveloper is rich platform. As rich as NetBeans Platform and in some sense even larger. I am always amazed when I look at JDeveloper code to find out it solves some general problem we had in NetBeans as well! Of course the solution is not the same, but clearly the original problem was very similar. Oh those Parallel Inventions, oh those little differencies!

Significantly changing the JDeveloper platform would have very disturbing Big Bang effect. Rather I wanted to offer small steps towards shared base allowing additional code exchange. OSGi seemed like a good candidate. JDeveloper architecture follows concepts of JSR-198 and thus a sketch of [modularity]] has always been present there. I was hoping that adopting OSGi could be natural next step sometime in future.

You would not believe how surprised I was when I found out (during first Prague visit of Oracle guys in April 2010) that they had already rewritten JDeveloper to run on top of OSGi (thanks Stoyan!). I was surprised, but pleased, as this validated our decision to support OSGi in the 6.9 release! We almost reached the common ground without even starting to talk to each other.

Performance

We had the common ground I was hoping for. Just NetBeans 6.9 primarily supported Felix and JDeveloper relied on Equinox. However NetBeans could run with Netbinox as well. 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:

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

Clearly, sharing some code between JDeveloper and NetBeans helps the JDeveloper users to get better product. Such users will get support for their favorite technology the way they are used to, just sometimes it may be faster, and sometimes it may look nicer thanks to the NetBeans Platform.

Sharing also helps the NetBeans team to get into better mood. It always makes you happier to know that your work is used. If it is used by a strategic product of your own employer, it can help you feel confident. In fact few team members who left during last two years are returning back, and that is a sign of regaining trust.

The sharing also helps NetBeans users. Thanks to this effort they can use OSGi and have access to Netbinox. Unless we spoil something, the sharing will continue. Not only it will help NetBeans Platform to get better, but it will ensure it is needed. Is this not what every NetBeans Platform adopter wants to hear?

<comments/>