about why the best of possible worlds would involve Oracle building on top of the platform and moving JDeveloper's Oracle functionality over to NetBeans as  Platform modules.  It's not like we are talking a huge technology bridge - say like moving to an alien, native API - no  both NetBeans and JDeveloper are built using the Swing toolkit.  Get with it, Oracle.  Move your developers  to a great Java Platform solution and and the best IDE available.

[Update : I found this out just now, yet another very recent adoptee  of the NetBeans Platform, is NASA.  You can read the details here .]

If you look at this chart it does seem impressive. Really ? Does JDeveloper really have a larger community - uh no...anyone that has followed JDeveloper understands it's niche so now let's really spend time with this chart.  First, and as I said previously - a while back I gave up on the usefulness of  comparing the number of job postings of one IDE versus another relative to jobs. Why ?  Because the vast, vast  overwhelming majority of Java job postings don't bother specifying an IDE - so such a chart loses meaning.  I warned about this in the blogposting.  Now let's take the chart above and add total Java postings. 

Okay, now you understand.  Yes - that orange line that merges with the number zero is what Shay is saying is important, perhaps removing your attention from that solid green line that is not zero and shows the Java job postings.  The point is that specifying an IDE with Java makes sense only in a few contexts.   In fact, the only ones that do specify an IDE are companies have something very unique that needs to be done - something like Eclipse plugin development, NetBeans plugin development or JDeveloper ADF development. In other words, and according to the chart ... almost zero when comparing them to the total number of Java jobs.   The total number of jobs that are using Java dwarfs those jobs needing specific JDeveloper and NetBeans needs.   Shay's chart means nothing other than  companies needing proprietary APIs to be built such as ADF and Oracle APIs  need to specify that. With the exception of NetBeans RCP (which is open source) there is nothing to specify with regards to NetBeans (it's Java, Java EE, Java ME, Grails, Ruby, PHP, Python, etc that end up being specified that are pertinent to any NetBeans developer).  So I would completely expect there to be more Oracle developers dealing with a lot of proprietary Oracle APIs than developers building RCP apps - but at the end of the day it approaches zero when compared to the number of Java jobs.  As the evidence of the job posting chart show, the overwhelming majority of postings don't need to specify NetBeans, JDeveloper, Eclipse, etc.    So, this is why Shay's chart lacks meaning - it is stripped of the real information you need. [ update : Incidentally this isn't the only person/group that has posted this type of chart.  MyEclipse recently did the same thing and the results are the same as you can see from this graph.  Again, the vast Java job numbers result in the same thing, MyEclipse job numbers graphically merge with zero when compared to overall Java jobs. In the end, this type of marketing backfires when people find out what is happening. ]

Shay also attempts to explain why JDeveloper really does have a community.  Shay, I know it has a community but from every indication it doesn't seem to be very big and it is very, very focused on Oracle's proprietary products and APIs.  Since we mention surveys, personally, I like Developer.com's voting for Product of the Year - it doesn't pretend to be impartial - users simply vote for the products they use and like. Interestingly, NetBeans won the IDE of the Year last year. I didn't see JDeveloper on the runner's up list..anyway back to the topic at hand - the study you reference is, not surprisingly, skewed in a number of ways and well, we can all pick a favorite survey or study.   First,  it refers to Java IDEs - NetBeans does C, C++, RoR, Python, PHP, and bunch of other non-Java languages.  Which, of course, we know JDeveloper does not. So, with very little effort, you can see that JDeveloper playing in only the Java space is going to have less developers.   You can see from the next chart that there is more to software development than Java.  NetBeans does all those languages on the chart- and that ends up where JDevelopers falls down very badly -

Second,  while it is great that the survey of readership you refer to actually shows NetBeans has large usage (in this case 1/4 of the market - my guess is somewhere between 1/4 to 1/3)- my impressions are that the survey is probably wrong on a number of counts. The same company,  had actually done another study on  Eclipse usage which you can find on their site (relevant question is 24). So a couple of studies during the same time period with very different results and surveying the same readership, hmm.... I'm not sure I buy any of it.  By the way,  the other one shows NetBeans/Sun Studio (Sun Studio is the C/C++/Fortran version of NetBeans) at 21% and JDeveloper at 14%.  So that's a full -6% difference in the same year for JDeveloper. I tend to lend less credence to these surveys - especially if they have been paid for by somebody.  Call me cynical.

The point that is missed is that most reasonable people understand that NetBeans has a much larger community even if they use (questionable) readership survey numbers.   Oracle would be hopefully focused on addressing on how to make these communities larger and more vibrant.  I can think of a couple of ideas to do that.  One way is to announce real choice to your JDeveloper community by doing the following plugins for NetBeans :

So it  really does get more interesting - NetBeans and Eclipse also have a presence in other languages - let's pick C, C++ and Fortran.  How many people use JDeveloper for C and C++ ?  Eclipse  and NetBeans C/C++ developers do that everyday of the week. Besides the NetBeans C/C++ plugin, even more interesting is Sun's Studio, a sophisticated development environment for C, C++ and Fortran, it is written using the NetBeans core platform APIs.  By the way - this is an example of the notion of platform that JDeveloper misses - Sun Studio is not simply written with the NetBeans IDE - it is written to use the core Platform APIs that allow it to use a huge number of the core platform infrastructure that is found within NetBeans itself.

Now let's look at Ruby - does anyone spend anytime at all (is it even possible) to do Ruby development on JDeveloper  ?   They do on NetBeans.

Or PHP ? Check out NetBeans IDE for PHP.   Want to catch a movie about it ? Check the blog.

Even if you go and look at the Grails website of IDE's to use (as of this writing) - where is JDeveloper ?   Yes in one of the few areas JDeveloper allows you to write in nobody thinks to even put JDeveloper down because there are better choices in the form IntelliJ, NetBeans and Eclipse. You can find a NetBeans Groovy/Grails example on the Grails site

An then there are a large number of other languages where JDeveloper doesn't even have any IDE support.  Where is JDeveloper's support for Scala ?

In effect, developers that are forced into using JDeveloper are stuck on the ship of Oracle products and APIs - there is no getting off because they need support of those products and APIs.  It's not that JDeveloper is an awful product, it is a highly competent product for what it does - it is very good for a number of things - it is simply that there are better IDEs out there that have much larger, vibrant communities, that do more and support a larger set of developers and languages and offer core platform APIs.  It is that simple.  Oracle has an opportunity to create a set of Oracle plugins and features into NetBeans that support the Oracle product set and gain the support of a large community of developers.

This is why Oracle has missed a huge, huge  opportunity.

I will continue to create "the list" with the idea that (a) it might give a developer a perspective on what people are doing (b) how they are constructing their apps.  I also encourage developers to look at the extreme Swing series from past JavaOne conferences.  

Meanwhile, I do see the beginnings of JavaFX apps beginning to emerge such as musicpin from GUI thought-leader, Canoo,  and Indaba's Collaborative Digital Audio Workstation.  A JavaFX development tool, JavaFX Builder, is also available and is very interesting.  However, surprisingly, that seems to be it except for the recently concluded JavaFX contest .  If you know of others I would love to know about them.

It is entirely possible that the arrival of JavaFX has confused some  developers and this confusion may have even caused problems for Java on the client-side.  Why has this happened ?  I have to remind myself where JavaFX is aimed at going - Sun has announced JavaFX is aimed at the - [a] desktop [b] mobile and [c] interactive devices including television.   Perhaps the tag line about JavaFX being for "all the screens of our life" has served to confuse things even more.  For the same reason that an aerospace company would choose the Swing/NetBeans Platform over Flex or Flash - I also would make the same choice and probably for the same reasons. To these developers and companies, they will look at JavaFX as being in the same RIA boat (and it is) and they look at it as containing less architectural flexability than a Swing RCP (modules/plugins, resources, RCP structure, etc).  The vagueness and marketing tag lines have served to confuse a fair amount of people and I am not the only one that thinks that. 

If you have followed this blog then you know that I have been very supportive of JavaFX (you can see from my past JavaFX blogs ) - JavaFX has its place - but that space is a lot smaller than the JavaFX marketing suggests.  Over time issues have emerged  that really need fixing and after some discussions with other Swing developers at JavaOne and post-JavaOne it looks like I'm not the only one with these feelings.  What's wrong with the JavaFX ? 

JavaFX does not currently satisfy all the screens of my life despite the marketing tagline.  Some will erroneously view this as an attack on JavaFX - it is not.  This is simply part of the  community discussion that has already started and is aimed to make JavaFX better - the starting place needs to be integrating JavaFX and Swing in a as a meaningful  two-way street (the answer to "it's hard" - is "most good things are"),   provide better transparency into its roadmap and making it open source. At JavaOne I was asked for my opinion on using JavaFX in real apps - I answered (after going through some of the issues above) that it depends on the type of app and it depends on your comfort zone with the above issues.

----

Please note the second part in this series -  Follow-up On Fixing JavaFX and the discussion on DZone .