NetBeans may be a hedge for ISVS against messy client choices

NetBeans may be a hedge for ISVS against messy client choices

Summary: These are just the sorts of things that Oracle is thinking over as it decides what to do about NetBeans.

SHARE:
TOPICS: Open Source
4
I just had an intriguing analyst briefing with some NetBeans folks at Sun Microsystems, and I'm beginning to think the public discussion on the Eclipse-NetBeans thing (or is it mostly the SWT-Swing thing?) is missing the larger strategic perspective. From the vantage of an architect or CIO -- and not necessarily strictly from the view of developers -- there could be a lot more to NetBeans and its tools progeny, Creator and Studio, than meets the eye.

My new-found interest in NetBeans 5.0 comes as a result of the different fundamental directions that software development is now faced with. These are just the sorts of things that Oracle is thinking over as it decides what to so about NetBeans. Indeed, there are multiple imperatives that factor into how to best plan for future software development, and they are not well aligned. They are actually increasingly at odds. Smart ISVs will seek a way to mitigate risk, and avoid being led down a garden path to less than optimal addressable markets.

One imperative (let's call it the legacy client support one) suggests that planners should designate tools, frameworks, and platform targeting based on applications that must for a considerable period of time target and span multiple and divergent native client targets -- from PDAs to cell phones to the usual gang of PC platforms, Windows, Mac, Unix, and Linux. The largest camp here is Windows-based clients, and there are a lot of them and they are not going away any time soon.

Another imperative (let's call it the client-agnostic one) suggests that planners should move beyond legacy clients and make their strategic development choices based on the primary concerns of server-side logic and frameworks as targets, of moving as quickly as possible to applications that reach the end users via server-managed clients, browsers/portals, and the rich mix from AJAX, REST, and the Web 2.0 stuff. There's a lot of momentum here, and enough client-side Java and browsers across the legacy clients to make this a compelling philosophy.

Anticipating these imperatives are the Eclipse ecology constituencies, which certainly seems to favor the move away from native client targets and the messy plug-ins process that entails toward applications of, by, and for the server. This direction was given a boost this week when IBM at Lotusphere announced that the latest multi-purpose clients, WorkPlace 2.6 and the forthcoming Hannover version of Notes, will not only both be server-managed clients but that the WorkPlace 2.6 client plus IBM's portal server will become the preferred GUI-tier for SOA and composite applications for all of IBM development. Java on the client is, of course, supported, but multi-purpose is the key. This is significant.

One can surmise that new levels of extended enterprise productivity and business process automation will become the strong breeze in the sails of the Eclipse community toward the tightening embrace of the client-agnostic imperative. The strategic development tools choices, then, should focus on how to organize, attach, and manage the services among and between the servers, not the clients.

Also anticipating these imperatives are Windows ecology constituencies, which certainly seem to favor the "connected computing" approach enabled by the Microsoft Visual Studio 2005/.NET/Vista/Indigo/Avalon assortment. Their direction seems to re-encourage a tightly coupled client (especially Office 11/12), and to a lesser extent support browsers and AJAX-like GUIs. The convulsion in terms of how to balance the fat client with the rich client for Microsoft was evident at last October's PDC, and the subsequent memos and reorganization announcements. It has not been settled yet, and the market will ultimately decide (this time).

And then there is NetBeans, which seems to have quite a bit to support both of the imperatives, and also has the lynchpinadvantage that it deeply supports Java at every twist and turn. And it turns out that Java has a strong and encompassing role to play for the legacy client support imperative. And Java has a strong and encompassing role to play in the client agnostic/server-supreme imperative. I'd say that Java has quite a bit more to offer the server development productivity side of the equation, but using Java as the means to target clients from Mars rovers to the latest JVMs on cellphones, PDAs, Windows, Mac, Unix, and Linux is a strong plus too.

I have not changed my take that Java is heading toward legacy status, and that the future is all about SOA. And that the Java community is putting their resources elsewhere. But Java has not yet played out its transformative role for software development and deployment, and that means its influence is still highly significant.

So has the discussion of Eclipse vs. NetBeans, or SWT vs. Swing, or GPL vs. CDDL, missed the point? For those enterprise developers, and especially ISVs, that need to hedge their bets by being able to move on a dime regardless of how the world plays out -- fat client, rich client, thin client, no client -- is NetBeans a risk reducer? Is the common denominator of Java to NetBeans a strategic advantage that no one but Sun can manage and extend, and which is neither controlled by Microsoft nor IBM? If you embrace NetBeans as an ISV in addition to Eclipse and .NET can you be more fleet toward the largest addressable markets for your goods and services?

Now that NetBeans 5.0 has some strong feature-function strengths -- Matisse's GUI creation, better profiler, editor enhancements, plug-in support -- does the unique ability to straddle the divide between where Microsoft needs to go (fat client) and where IBM wants to go (rich client) make a sizable difference? Does it now make good sense to make sure, if you're a Microsoft shop, to embrace NetBeans and train some of your developers on the free Creator tools? Does it now make good sense, if you're an Eclipse shop, to make sure you have a handle on NetBeans to ensure that you have an end-to-end Java strength (as that becomes finally possible) and while IBM walks away from Java on the client?

These are questions I had not spent enough time on until today. I think these are just the sorts of things that Oracle is thinking over as it decides what to do about NetBeans. SAP will be focused on this too, Mendocino not withstanding. This is beginning to make me see NetBeans in an entirely new light, as an extension of what made Java so good for the industry.

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • Eclipse is currently the best hedge

    Between Eclipse and NetBeans, Eclipse is currently the most flexible as far as client choices go. Eclipse can host Java SWT, Swing, ActiveX, and .Net controls. Eclipse RCP apps run on a wider variety of platforms, notably mobile devices (PocketPC, Nokia, etc.), and it has a standards-based plug-in underpinning (OSGi). There's even a project now for Eclipse on the server side which looks like it may have legs.

    In addition, there is no evidence that supporters of Eclipse such as IBM are walking away from Java. Quite the opposite in fact. Most of the SOA work is being done with Java in any case.
    Ed Burnette
  • Interesting perspective on Eclipse

    Dana,

    Sorry I really don't see the hedge that NetBeans offers. Eclipse provide first class support for Java, so I am not sure what 'end-to-end Java support' we are missing. We also support all the different client and server models. Eclipse and the Eclipse community are very coommited to Java on the desktop. Eclipse Rich Client Platform (RCP) is being adopted by ISVs as the platform for building end user Java desktop applications.

    The good news is that hundreds of ISVs are building on top of Eclipse, so I don't see anyone hedging.

    btw, I expanded on some of these points at <a href="http://ianskerrett.blogspot.com/2006/01/interesting-perspective-on-netbeans.html">blog post.</a>

    Ian Skerrett
    Director of Marketing
    Eclipse Foundation
    IanSkerrett
  • JSF is the weak link in your premise

    JSF, as the centerpiece of Sun's Creator RAD tool for the web, is
    the weak link in your premise. The problem is that it is fatally
    flawed architecturally and there will not be sufficient uptake by
    Java developers - as most of the savvy ones are already in the
    know regarding its problems.

    Sun and Oracle will only have limited success in trying to force
    JSF down the throats of developers via their managers (i.e., the
    old tactic of using managers to arm twist developers into using a
    particular technology because of a pre-existing vender
    relationship - didn't help Oracle one iota in getting their J2EE
    app server to be widely used).

    The problems of JSF that I refer to are not at all due to the rival
    Ruby on Rails or the like. The fatal problems of JSF are intrinsic
    in JSF itself. I refer anyone that is curious to these links:

    JSF: The 7-Layer Burrito I Won?t Eat Again
    http://timshadel.com/blog/2006/01/19/jsf-the-7-layer-
    burrito-i-wont-eat-again/

    JSF: Leaky Abstractions (Grab a Mop)
    http://timshadel.com/blog/2006/01/24/jsf-leaky-
    abstractions-grab-a-mop/

    JSF: RenderKit Blues
    http://timshadel.com/blog/2006/02/03/jsf-renderkit-blues/
    rogerv
  • RE: NetBeans may be a hedge for ISVS against messy client choices

    Dowloading.
    thanks for sharing! <a href="http://www.replicawatches.me.uk">cheap replica watches</a>
    tank33