JDeveloper
From APIDesign
(→Performance) |
|||
(16 intermediate revisions not shown.) | |||
Line 1: | Line 1: | ||
- | [[wikipedia:JDeveloper|JDeveloper]] is the primary IDE to support [[Oracle]] non-open source technologies (like [[wikipedia:Oracle_Application_Development_Framework|ADF]]). I really like [[JDeveloper]]'s support for working with [[XML]], it is far better than the [[NetBeans]] | + | [[wikipedia:JDeveloper|JDeveloper]] is the primary IDE to support [[Oracle]] non-open source technologies (like [[wikipedia:Oracle_Application_Development_Framework|ADF]]) and a base for various other [[Oracle]] technologies like [[SQLDeveloper]]. I really like [[JDeveloper]]'s support for working with [[XML]], it is far better than the [[NetBeans]] equivalent. |
== Before Acquisition == | == Before Acquisition == | ||
- | When we learned that [[wikipedia:Sun_acquisition_by_Oracle|Sun would be acquired by Oracle]] in April 2009 we knew we | + | When we learned that [[wikipedia:Sun_acquisition_by_Oracle|Sun would be acquired by Oracle]] in April 2009, we knew we needed to modify [[NetBeans]] to be ready for the acquisition. We tried to guess what would make [[NetBeans]] attractive to [[Oracle]], but it was almost impossible to do so because up until the first quarter of 2010 (when [[wikipedia:Sun_acquisition_by_Oracle|the acquisition]] was approved by the [[wikipedia:European_Commission|European Commission]]), there were no signals from [[Oracle]] to help us understand its [[NetBeans]] intentions. A tough situation, complicated by the fact that people were being fired every few months and those who stayed had little faith in the future. Still, I hoped we would get a chance to prove that [[NetBeans]] (and the [[NetBeans Platform]]) could be useful to Oracle. |
=== Common Ground === | === Common Ground === | ||
- | Slowly it became clear that the crucial part | + | Slowly it became clear that the crucial part was 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: |
{{#ev:bliptv|2790848}} | {{#ev:bliptv|2790848}} | ||
- | I convinced my management and [[netbeans:OSGiAndNetBeans|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 [[Swing|standard UI toolkit]], but also de-facto standard [[module system]]. Everyone could benefit, but I admit my primary motivation was to | + | I convinced my management and [[netbeans:OSGiAndNetBeans|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 [[Swing|standard UI toolkit]], but also de-facto standard [[module system]]. Everyone could benefit, but I admit my primary motivation was to meet [[JDeveloper]] half-way. |
=== Other Side of the Ocean === | === 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''! | + | [[JDeveloper]] is a 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. | + | 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. | 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. | ||
Line 23: | Line 23: | ||
== Performance == | == Performance == | ||
- | We had the common ground I was hoping for | + | 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: | [[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: | ||
Line 51: | Line 51: | ||
== Sharing == | == 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 | + | 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 [[Netbinox|faster]], and sometimes it may look [[netbeans:WinSys71PressRelease|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 | + | 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 [[netbeans:OSGiAndNetBeans|OSGi]] and have access to [[Netbinox]]. Unless we spoil [[netbeans:WinSys71PressRelease|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 | + | The sharing also helps [[NetBeans]] users. Thanks to this effort they can use [[netbeans:OSGiAndNetBeans|OSGi]] and have access to [[Netbinox]]. Unless we spoil [[netbeans:WinSys71PressRelease|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/> | <comments/> | ||
[[Category:Video]] | [[Category:Video]] |
Current revision
JDeveloper is the primary IDE to support Oracle non-open source technologies (like ADF) and a base for various other Oracle technologies like SQLDeveloper. I really like JDeveloper's support for working with XML, it is far better than the NetBeans equivalent.
Contents |
Before Acquisition
When we learned that Sun would be acquired by Oracle in April 2009, we knew we needed to modify NetBeans to be ready for the acquisition. We tried to guess what would make NetBeans attractive to Oracle, but it was almost impossible to do so because up until the first quarter of 2010 (when the acquisition was approved by the European Commission), there were no signals from Oracle to help us understand its NetBeans intentions. A tough situation, complicated by the fact that people were being fired every few months and those who stayed had little faith in the future. Still, I hoped we would get a chance to prove that NetBeans (and the NetBeans Platform) could be useful to Oracle.
Common Ground
Slowly it became clear that the crucial part was 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 meet JDeveloper half-way.
Other Side of the Ocean
JDeveloper is a 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:
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
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/>