Here's what's missing from the Gosling interview

Here's what's missing from the Gosling interview

Summary: Sun really wants to sell to the operators, and wants the developers to help them to do this.

TOPICS: Open Source

Interesting interview on with James Gosling of Sun Microsystems, mostly for what is not discussed. The tack that Gosling takes with Java leaves out three essential ingredients that the intrepid interviewer, Martin LaMonica, keeps trying to point to, but Gosling dodges.

1) Java has to be examined within the context of politics and power, not just technological capabilities and past market trends. Sun really wants to sell to the operators, and wants the developers to help them to do this. The politics is that Sun has alienated many of the largest Java community players. They have done this by insisting that Java is a tax, not an open standard. Sun has opined about how the economics of software has shifted to free and has waxed on about how the bazaar is where it's at, except for Java intellectual property. If Java were truly made open source three years ago, things would be very different.

The result is that the major Java ISVs and infrastructure vendors now view Java as a necessary legacy that they need to support, but are looking elsewhere to fund and expand innovation. Java is relegated to middleware plumbing, and as a partial solution to integration concerns.

Many large vendors, IBM as the exemplary example, essentially funded Java R&D so that Sun could later charge them to use it. They are not funding it anymore, and Sun does not have the wherewithal to lead on Java's future alone. The split over Java Business Integration (JBI) specification (JSR 208) is the future of Java politics, and it is not the direction of industry standards.

2) There is a gulf between what systems operators want and what developers do. Operators and developers work essentially in different but parallel universes. Datacenter and service delivery platform operators are motivated by much different forces of economics and productivity than are developers.

This gulf needs to be better bridged, yes, of course, and the incentives and vision of both groups need to be better aligned. This is a major cultural challenge for how well SOA actually pays off -- can app dev thinkers and deployment-minded thinkers be made to work in harmony across the software lifecycle?

However, Sun with Java has lost allegiance and panache with Western developers (regardless of what Gosling professes about China and India, which will follow suit with North America and Europe soon enough). Developers focus on the higher tiers of an n-tier architecture. The operators and the infrastructure architects focus on the big bucks platform purchasing decisions and strategic infrastructure direction calls. Both are still viewed as cost centers by CEOs and CFOs, but operators bear the brunt of cost-reduction edicts from on high.

Sun really wants to sell to the operators, and wants the developers to help them to do this. Architects are the key to it all: They know that Java is a link between the universes of development and deployment, but Java is currently being outshined in terms of the productivity-boost/cost-reduction appeal across all the groups: developers, architects, and operators.

Developers will continue to want to develop their way -- merrily scripting away within open-source frameworks -- to make their deadlines and adhere to the daunting requirements handed them. Operators will continue to look to x86 blades and LAMP to slash their costs and ease their server consolidation/unification efforts. Architects are looking to SOA -- not Java -- to integrate their businesses goals and IT assets on the higher planes of process productivity, process extensibility, and IT asset value repeatability.

So Java remains a necessary and essential ingredient, for sure (for years) but no longer is Java the driving force for major platform or development decisions. It is legacy. It is a boon to middleware functionally (not necessarily economically any more), and is increasingly buried inside the middle of the middle of the stacks, and lives there increasingly out of mind.

While developers and operators are motivated by different imperatives -- Java is not what's guiding them to the future, it's what brought them out of the past. SOA may very well make Java less relevant on an accelerating time frame.

3) Gosling can chat up Creator and Java-AJAX synergies all he wants, but that does not bridge the gulf between the popularity and community investment curves between NetBeans and Eclipse. Just when Sun makes Java development easier, they make the open source framework choice complicated.

IBM did to Sun with Eclipse what Sun did to IBM with Java (except that IBM went open source and Sun did not). Sun needs to face this and stop pushing on the string that is NetBeans. I'll take Berlind's side on the bet. Sun's better path to developer uptake and architect appeal to promote Java infrastructure choices by the operators is to use AJAX et al as a wedge to drag along Sun's tools and possibly their platforms. NetBeans is not going to polish the edge of the market wedge, but leaves it dull instead.

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.


Log in or register to join the discussion
  • What about cost?

    How much does a LAMP setup cost? If you want support, its probably a couple of hundred bucks a year at most. If you go with IBM's Websphere (as Company "F" has done), you are facing 15 grand per installation! Not to mention that by writing to the Websphere "standard" - you are trapped with using WAS FOREVER! That write-once Java code uses "proprietary" (IBM) extensions, so you LOSE that feature of Java.

    I for one, would not like to be hitched to IBM's wagon while bleeding cash (like my employer) - but single-minded management isn't looking to save money - only "defragment". Oh well, I wish them luck (with my pension in the balance . . .)
    Roger Ramjet
    • Cost doesn't have to be an issue.

      There are free Java app servers. As for writing to the Websphere standard, that depends on the requirements of your project or how disciplined the developers are. We are tied to Weblogic JMS, but the Weblogic class we used is isolated, and before we married Weblogic, our pile of code ran on two other app servers without modification. My point: Company "F" is tied to Websphere if they need something only supported in Websphere, or its developers did not have the discipline to look in generic Java docs to find out how to do something.

      It is considerably easier to get tied to a database than to an app server. For instance, if you use Oracle stored procedures or any of the Oracle specific commands, like DECODE, it is more than likely not isolated, but scattered throughout your application. Then even if your app is not tied to an app server, it is tied to a platform that supports your database.

      As for LAMP, I have a problem implementing enterprise applications using scripting languages, where the business logic is intermingled with presentation logic. Doing this opens other cans of worms, for instance, scalability and security issues. Using LAMP on large projects, is just like implementing all of the business logic on a Java app server in JSPs -- faster in the short term, but you'll more than pay for it later on.
  • Java just sucks, plain & simple

    There isn't really any RAD for Java that's worth anything - free or not. The language is a cluster of complication and fragmented logic that turns even simple projects into a big production. It seems to be a giant step backward for development. I have to use it, but the day it goes away won't come soon enough.
    • MVC just sucks, plain and simple

      That's not true. For me, Visual Studio sucks more than Eclipse or Netbeans (if those are the two RAD that you think of). As Java, I use it a lot for desktop apps of approx 1 MB, and it seems to me very simple to use. Look at VC++ with MFC : nobody would say that it's easy to use, I tried it for several little apps, and it's not user friendly at all, even for small things. You have to let VC++ generate a lot of code, there's soon GUI files everywhere, and you have to be very smart to know whre to put the necessary hooks to your app code...
      But maybe I'm not smart enough, so it's all right for me to use Java, because it's easy to do easy things...
      OK, as for C#, it borrowed a lot from java, so it seems that Java does not suck as much as you say.
      • Performance & scalability

        C# borrowed from Java and Java borrowed from languages that came before. I don't think it's the problem though.

        My take on the problem
        I can not recall having seen a single Java application that convincingly outperforms or outscales a comparable C/C++ application. This may not be a big issue on the server-side because you can throw more memory and CPUs at the problem but this may not be possible on resource-constrained clients.

        This problem is not inherently Java's but is attributable to the overhead of using a VM, which is key to Java's portability. At a time when SOA is coming into its own, does anyone really care about portability? Well, we probably do care about portability on the server-side but we can accomplish that using LAMP anyways, no? If you're careful, you can even keep your business logic separate from your presentation logic or so it seems.

        Although I've read that JVMs can manage memory automatically more efficiently than I can by myself, I have yet to see any tangible evidence of this. In 1995, I accomplished more on a server with two 200Mhz CPUs and 128MB RAM running C++ apps than I have today on a server with four 2Ghz CPUs and 5GB RAM running Java apps.

        Even on a late model 5GB machine, I deplete my memory far frequently today than on my server from 10 years ago. I think that the root cause (in terms of memory management) is Java's garbage collection algorithm, though intelligently designed does not know and can not be expected to know my applications nearly as well as I. Only the developer can develop a heuristic that optimizes memory usage globally. Java doesn't let me do that. The only way that I can force a deallocation is to perform a system exit or increase the priority of the GC thread, which slows the application, appreciably in some cases.

        This is not to say that Java does not work or is devoid of value. There has been a considerable body of work built on and around Java, much of it open source, that IT organizations like my own can tap at little or no cost. Also, Java applications tend to be more standards-based which makes them theoretically easier to maintain. The same can not be said of proprietary technology from Microsoft, for example.

        I will continue to use Java on the server-side where it makes economic sense. However, since, as you pointed out, C# borrowed a lot from Java, it may be not be cost-prohibitive (training-wise) to switch over to C#, LAMP or something else that gives us a better handle on performance, scalability and resource management.
    • RAD in what sense?

      You don't really say anything other than Java sucks. Why? What for? What is missing/bad in terms of RAD in Java? What is a simple project to you? What is a complex project? What makes Java that much worse than Visual Studio etc?

      Are you just venting, or what?
      • Jva Rocks

        Go ahead and bash Java. I take my job and education of object oriented programming very seriously, and because of that I make 100$/hr. I do not see any php programmers getting even close to that. Cause php is EASY and Java is DIFFICULT. But, for enterprise plumbing, like the author said, Java is here to stay forever. And in the meantime, php hacks will continue to show up 10-1 over Java vulnerabilities.
        • Difficult vs. Easy

          Economically, which to adopt...(1) an easy to use programming language with which developers can ramp up faster and be productive sooner or (2) a hard to use one, the break-even point in terms of investment that may come at a much later date.

          You assert that Java/Object Oriented Programming produces higher quality applications with 1/10 the number of defects. Do you have any objective evidence that validates up that claim? Can not high quality be achieved using other programming languages as well with improved training and quality control?
    • Sucks long and slow

      Amen to that Brother!

      It might be worth the overhead to create some multi-platform browser-based behemoth but it's so knotted and strangled that it's usually not worth the effort. The main folk making any cash are those selling more "libraries" to other struggling developers.
  • "Out of mind" is good, and more

    > It is legacy. It is a boon to middleware <br>
    > functionally (not necessarily economically any<br>
    > more), and is increasingly buried inside the<br>
    > middle of the middle of the stacks, and lives<br>
    > there increasingly out of mind.<br>
    When was a language/platform anything *but* middleware? The fuel lines in my car are buried in the middle of the middle of stacks, and are definitely out of mind. But that doesn't mean anybody's going to start selling cars with no fuel lines.
    I think you're confusing the amount of attention a technology requires in order to use it with the utility of that technology here. The fact that it's possible for Java to be out of mind for people who are using the technology is about the best indication of its success you could ask for, far from being a death knell.
    > SOA may very well make Java less relevant on <br>
    > an accelerating time frame.<br>
    Let's contemplate for a moment what SOA is: Procedural programming over the network with a degree of fault tolerance. Very sound 1960s engineering advice, but far less there than meets the eye. And at the endpoints of that network are computers which are running software. And behind those computers are people who make choices about what hardware to buy and what software to run. And there, the choices are the same as they have always been - would you rather have preserve the possibility to migrate or scale up the thing you're deploying, or are you comfortable with imposing a high cost of change on yourself in the future? How good is your crystal ball? The portability promise of Java is still the best answer the industry has to that set of problems. It's precisely <i>why</i> it's possible for it to be "out of mind" as it were.
    > If Java were truly made open source three <br>
    > years ago, things would be very different.<br>
    Things would indeed. There are companies with large consulting practices which would like absolutely nothing better than to get their consulting customers on an ever-so-slightly incompatible version of Java, and that's exactly what would have happened. Java definitely wouldn't have be "out of mind" as you say - more likely the Java middleware market would be collapsing just about now.
    > NetBeans is not going to polish the edge of<br>
    > the market wedge, but leaves it dull instead.<br>
    I'd respond to this better if I could decipher it. What I will say is this: Looking at the Eclipse Web Tools project or Visual Editor, they are far, far behind what NetBeans offers to developer for functionality, productivity and user experience. Don't take my word for it, find a developer who hasn't used either and have them create a GUI and a 3 tier web app and see what they tell you.
    NetBeans is the second most used Java development tool on the planet, and the adoption growth curve over the last year is nearly vertical. What it does make me think of, oddly, is WalMart.
    For many years, industry analysts panned WalMart. Not sexy. Not hip. Not clever. Not cool. And the whole time, WalMart was quietly gobbling up the retail market, pooh-poohed all the while by the retail glitterati.
    It would be nice to have for NetBeans the geysers of gushing praise and wonderment from the press and analysts that accompanies every navel-gazing announcement from the Eclipse organization (as it continues to fail to execute). But it's far from an essential ingredient for success.
    • the endpoints

      Over 60% of all servers run Windows but under 50% of all web applications are written in Java today. Certainly, it doesn't seem that Java is as ubiquitous or as indispensable as James Gosling and others would have us believe.
  • Architect viewpoint

    Excellent article, I liked the politics part which is ideed very important to be taken into consideration for strategical choices. I found also interesting the Netbeans part, between the lines, I have understood that Sun is kind of weakening Java by confronting NetBeans with Eclipse.

    I think Java has become a generalistic language, good to do all kind of things but in every particular area, it will be possible to find a better alternative.

    SOA is far more important for architects because SOA allows us to make the technical choices (language, OS), less-important choices.
    Rich Internet Applications is the last demonstration of this, we can now even use a different language for the view and the business layers of one single application.

    Mixing languages makes sense sometimes, it is for sure required in large enterprise environments but there are also drawbacks to this if I take into consideration the skills that are needed to maintain such composite applications.

    Java remains a very pragmatic choice. If Sun does not want to have Java becoming brittler, they will have for sure to address the ever increasing learning curve by simplifying even more the language and focus on increasing developers productivity in the language itself, not in the tools.

    I believe that forever backward compatibility might kill Java at the end of the story. Does Microsoft worry about compatibility between Visual basic 6 and VB .NET?
    Let's put Java on a diet or let's create an light, cleaner Java on top of that JVM. But wait a minute, is that what Groovy is all about?
  • Someone's got a personal problem....

    I am a staunch supporter of open source development and an active user of LAMP. However, certain bloggers and columnists are allowing their own private peeves (with Java) to cloud their objectivity. LAMP is being used more often than not for web development because the tools are free and the learning curve not as steep as Java (or .Net).
    Open source technologies, like proprietary technologies have their own pitfalls. SUN did the correct thing in not having Java open source. Think about the myriad of Java possible implementations, much like different flavours of Unix and Linux.
    LAMP and Java are two vastly differing technologies, that, as Mr Gosling said, compliment each other. (Educated Analyst) Bloggers are constantly pushing the silly notion of LAMP/Java battle for web development. LAMP is easier, and was created specifically for web development. Java on the other hand is a much more versatile and multi-faceted programming language, that CAN be used for webdevelopment.
    So what if LAMP predominates webdevelopment? Since when was Java known as the premier language of choice for web development. Those who do so, do so mostly for consistency with their back-end enterprise (java-based) software layer. Can LAMP replace Java at the enterprise and middleware level?
    LAMP vs Java is a very, very poor and inapproriate comparison.

    So if you don't like Java (or more appropriately SUN, as more than often seems to be the case), hey use LAMP, WAMP XAMP or .Net

    Please stop the FUD.
    • Can LAMP replace Java at the enterprise and middleware level?

      I think that it's a good question. Can it? Certainly, application servers and certain technologies associated with LAMP like Perl have been around longer than Java and server-side applications have certainly been developed without Java in the past.

      It may be possible for Sun in consortia with IBM, Oracle and other vendors to establish an open standard for Java like for ODF that would discourage the proliferation of incompatible versions. Additionally, the industry trend appears to be for decoupling of enterprise applications from their native technologies not tighter integration (witness the porting of Oracle ERP to IBM Websphere and DB2) so does not appear to be much incentive for developing proprietary features much longer. Why would anyone limit their market potential in the long term by creating technologies that only run on a particular technology stack or platform unless of course you're marketing the iPod?
  • Technological obsolescence

    You bring up many good points. Java may be in the process of becoming obsolete in the same way that other technologies like Cobol have, slow and gradual. Java is 10 years old. Most technologies have a life-cycle of no more than 20 years. Why would Java be the exception to the rule?

    However, the uptake of Java in China and India may actually buck the trend in North America. They do, afterall, operate under a different culture. They are technical in the same way that we, North Americans, are pragmatic. They may value Java in more ways than economic. Any thoughts on this?

    Additionally, a colleague of mine presented me with Java 5.0 a year ago and shown me how it was easier and simpler to use much like Groovy is compared to past versions of Java. For example, I don't have to use explicit type casting in quite so many places. These simplications in 5.0 might just make it economically competitive with some of the LAMP based technologies. However, I tend to agree that the days of Java as the driving force behind IT are over. Any thoughts?

    One thing is certain, Cobol, despite dire warnings of its demise is still used in data centers around the world (or so I heard) although I haven't actually met any one in five years that programs in Cobol. I'm sure that even if Java slowly recedes from the computing landscape, Java developers will have work to do for years to come.
  • What's missing might be a lack of bias ...

    > Gosling can chat up Creator and Java-AJAX synergies all he
    > wants, but that does not bridge the gulf between the
    > popularity and community investment curves between
    > NetBeans and Eclipse. Just when Sun makes Java development
    > easier, they make the open source framework choice
    > complicated.

    That curve is radically becoming less obvious. Netbeans
    adoption is rapidly increasing. Yes, Eclipse is ahead. But Eclipse
    has it's own share of problems and issues which give developers
    pause. In addition, if we were governed by mere acceptance of
    what was popular, we would all be on Windows (goodbye Linux,
    goodbye alternatives). Competition is *good*... it fuels
    innovation. On of the reasons why Netbeans is so much better
    today (5.0 .vs. the legacy 3.x versions) is precisely because
    Eclipse gave Netbeans a deserved kick in the pants ... and I
    suspect that Eclipse may get it's own kick over time as well. As
    for me, I would take Bray's side of the bet ...
    Robert Brewin