Catching the Java Wave

Open sourcing Java was the buzz at JavaOne, and discussions among attendees influenced part of the 2006 Java Technology Roundtable. Find out the experts' views on the state of Java.

The JavaOne opening keynote provided the answer that many in the Java community were hoping to hear: the revelation that open sourcing Java was, according to Rich Green—Sun Microsystems' executive vice president, Sun software—and Jonathan Schwartz—Sun's president and CEO—not "a question of whether, but a question of how." The news certainly touched off considerable discussion among attendees during the rest of the conference about the possibility of a second wave for Java.

As both executives noted, the desire to completely open Java with complete access is clearly there, but considerable challenges are ahead to maintain the compatibility imperative and thwart divergency as Java continues its evolution. Of course, other factors also contribute to the challenges: other languages and open source technologies, enterprises' heterogeneous environments, and matters of governance and compliance.

It was no surprise then that the issue at hand and the impact of these other factors for the Java platform were among the first topics addressed by the group of industry experts participating in the 2006 Java Technology Roundtable during the second day of the conference. Take a look at the Roundtable's initial discussion thread and their collective take on the second wave of Java and all that it entails.

The Next Wave
Simon Phipps: I have been talking to a lot of people around JavaOne, and there's a certain sense that we're about to see a second wave of Java. They're suggesting that the ease of development for Java EE means that there's going to be a resurgence of interest, that the open sourcing of the code in the future is going to open up new markets, and the availability on Linux is going to unleash a torrent of new opportunities. What do you think is the main highlight of the Java platform in the preceding year? What's the big deal that's starting the second wave, or is there not really a second wave? Sam?

Sam Pullara: I absolutely believe that Java will see a large resurgence. I started Gauntlet Systems last year, and we built almost entirely on open source software 90 projects for the dependencies when we got acquired [by Borland Software]. And one of the things we bonded to were all of the new Java EE 5 APIs, everything from JPA (EJB 3 at the time), to JAX-WS, to JAXB, and the thing about these new technologies on the Java platform is a lot of it was driven by what was perceived as a threat. Ruby on Rails, things like that are perceived threats because of the mind share that they garner, not necessarily market share.

The Java community has shown again and again that it can turn on a dime and adopt the good things that you see in other products, apply them very quickly, and get them adopted in the marketplace. I think that Java EE 5 will be adopted two or three times faster than the previous enterprise specs because of the ease of development.

Mike Milinkovich: One of the things I should have mentioned in my biography is at one point I [held] the lofty title of VP of TopLink, so I was pretty familiar with this whole area of persistence. My comment on the Java community "turning on a dime," is that's one hell of a big dime! That's more like trying to turn a super tanker.

Phipps: He didn't say how many times it would turn on a dime.

Milinkovich: Yeah, it's the whirling dervish turn on a dime, I guess, but I think getting POJO persistence into Java EE is something that is probably the big news for this year. I certainly agree with you on that. The only thing I change slightly is that I think it was a long time coming.

Ari Zilka: I would suggest that the JVM is really what enables people to turn on a dime. The community's a great community; no fault to anyone out there, and [I'm] not trying to say anything but. At the end of the day the JVM can do amazing things—absolutely amazing things. The notion of bytecode, what folks here helped build and what folks built back in the mid-'90s with this core concept, some stuff from Smalltalk, things like that have allowed us to basically [provide] the two stages of compile and then bring it down to the physical machine.

Obviously my company leverages techniques around this stuff, but what it means is that the developer's job is getting simpler. And what's happening is, Java EE is basically a response to the development community saying, "Hey, make my life easier," and what we haven't seen in the history of computing is a platform that can actually do that inside the infrastructure. As platform-level services we can subsume more and more from the developer's day-to-day responsibility. And, I think that's a huge thing.

I would add though that I don't agree that we have POJO persistence yet. I will go on record anytime, anywhere and say we fell short this year, and that there's going to have to be something more done. I have been to a lot of conferences this year where the same question comes up from the audience all the time when you talk to folks: "who's going to make my application simpler?"

Old News
Larry Cable: Well, I chime in to Sam's comments regarding J2EE… sorry, Java EE 5 (you can tell the vintage where I operate from). I really believe that Java EE 5, the usability initiative that's ongoing in there, is really going to develop a new level of applications and adoption in that platform. I kind of take issue with it being a response to Ruby or Ruby on Rails. All of the ease-of-use initiatives predate that technology by a good four or five years. There was a well-understood issue with the technology of separating out the declarative programming model.

I was part of the core architecture team for J2EE 1.2, and we did some radical things like inventing containers and bringing our declarative programming model to the platform, but we realized that there were some shortcomings with that. I think we finally solved that with the introduction of annotations that enabled us to kind of move back closer to a more developer-friendly platform.

I also think that key to the attraction and appeal of Java is going to be, as we saw in the technical presentation yesterday from Graham [Hamilton] and Bill [Shannon], the adoption of scripting languages on the EE platform being able to… I mean, when we did JSP 1.0 and 1.1, the reason that we put a "language equals" in the page tag was because we envisaged there being other scripting languages in the JSP environment other than Java, and it's—what is it—seven years since we did that to finally see one. Either we were incredibly visionary or just not very good at executing, but I really think that being able to bring VB developers into the Java platform and JavaScript developers into the Java platform, and encouraging client/server models like Ajax, that's really going to create a new wave of—I hate to use the cliché—Web 2.0 applications that are driven from the EE 5 platform.

Bob Blainey: I would agree that interoperability and the existence of multiple programming models is inevitable. [JSR] 223 is a great step forward. It shows you how to connect things at runtime. What we don't have is really kind of an end-to-end debug story and a management story for multiple different runtime environments, and that's got to come over time.

Phipps: Tim, I can see you're itching to talk about scripting languages over there.

Tim Bray: No, I don't want to talk about scripting languages. I'll talk about that later. Since everybody's been exuding sunny optimism about EE 5 and so on, I think a little bit of devil's advocacy might come in useful. For an outside observer, it would be easy to explain all the things we're seeing going on around EE 5 as a response to the fact that Java has been getting its butt kicked by PHP in various substantial, interesting, and growing sectors of the market. And by the way, as of Q2 2006, it's still getting its butt kicked by PHP in interesting, growing sectors of the market.

And Ruby on Rails is getting all the glamour and so on. I see Rails more as a bullet into the heart of PHP than into the heart of Java, actually. Personally, I hate PHP. It's awful stuff. It would really make me very happy if what EE is trying to do were successful in reclaiming part of that Web tier, low-rent, quick entry marketplace back, but it's not a sure thing. PHP is bad, but it's also good. I mean PHP taught us some lessons about share nothing and low barrier to entry and so on that Java still has a way to go to learn.

Pullara: Doesn't PHP run on the JVM now, though, so can't we revolt?

Bray: Yeah! And, here's the news, it runs on the JVM faster than the PHP does. So what does that mean? I don't know, but it's an interesting story.

Milinkovich: It means that the PHP VM isn't very good, but it's good enough, which is an interesting lesson for Java in itself.

Heterogeneity
Pullara: And to go back to my comments about Ruby on Rails, it's not so much that Java is competing with it, but it raises the visibility of Java EE 5 [for] people who may not have been keeping track of it and have sort of put off that EJB's never going to be usable, or this is never going to be usable, or that's never going to be usable. I think that Ruby in its attack on PHP, which I think is pretty accurate too—I mean that's mostly the people who are migrating to it—but what comes out of that though is the awareness that there is much simpler models and then people turn around and [say], "Oh, what's Java going to do for me?" Then they [say], "Oh, look, they've been working on it for years; here it is." I don't think that everybody follows it as closely as the people at this table do, and so it can look like, "Wow, you know they do have ease of use over there in the Java camp."

Dave Chappell: Well, from what I've seen the definition of the Java community has changed in that the JCP and the Java community are no longer synonymous with each other. Java has become more of an implementation detail of something you want to do, and I know I'm maybe pointing out what many of you already know anyway, but I think we live in a very heterogeneous world, and we're going to continue to live in that kind of a world. You can have Ruby on Rails and PHP and Java and all that working together.

In the circles that I run, which are the same circles that many of you do, enterprise is trying to just make stuff work, right? You've got to deal with all these platforms and technologies. I remember five, six years ago when coming to JavaOne was like going to the Mecca, right, to find out what's the new technology that's going to save everything. It's just not like that anymore. You know, it's kind of, okay there's really important stuff happening there, but it's part of the implementations of a lot of things that we do.

Rob Gingell: I agree that absolute homogeneity should neither be a goal nor should it be expected. On the other hand, two years ago I was heavily involved in the Java community on the production side. I'm now in an environment where I'm a complete consumer. I'm only academically interested in how it evolves and so forth. I want it to have a certain collection of properties for me as a designer, but in our business we're mostly serving people who are constructing SOA environments and so forth.

The idea that there be a resurgence in a tool like Java that would help people accelerate that would be welcome to us because we basically see that the SOA world, while holding a lot of promise, proceeds very slowly, and I think it's fair to say that one factor in why it proceeds slowly is this sort of large collection of things you've got to learn to do it with. I don't think seeking one ought to be an answer, but seeking fewer might help it in terms of how much an organization has to learn to do something.

Chappell: I would add that slow adoption of SOA is not about technology, but it's a whole other discussion and a half.

Phipps: That's a whole other discussion we're going to have in a minute.

Gingell: I agree there's a lot more to it than the technology part, but technology is a factor.

Too Many Choices
Zilka: I was just going to add an interesting anecdote to all of this, the topic of PHP, and homogeneity, and so on. I was called in maybe a year and a half ago to look at one of these large Internet sites, [a] viral community-type site, and it was a famous, very slow performing, grew-too-fast-for-itself kind of site. I was called in by its investors. They said it's running Tomcat and Java, and you seem to know it. Their VP of engineering said, "I don't know why you're here; we just switched to PHP two weeks ago and everything runs perfectly."

And I said, "What was the problem before?" just out of my own morbid curiosity.

He said, "The garbage collectors on the VMs couldn't keep track of session being added for every user fast enough, and we'd keep throwing out of memory, the VM would crash, and we switched to PHP and the problem went away."

I said, "Well you know PHP is stateless, share nothing, put all the burden on the browser, so you could have just configured Tomcat to be sessionless and be done with it in a couple of hours."

And he said, "Oh, we didn't realize that." Homogeneity is not good, but…

Jon Bostrom: But idiocy is worse?

Zilka: Well, a disgusting amount of heterogeneity is arguably far worse. When people have too many choices and the purveyors of core technology, platform technology, that everyone bases their business solutions on aren't forced to solve the core problems that all businesses have that deliver SOAs and be able to adhere to them, and so on, at the end of the day, it behooves us—the people sitting in this room—to help come to more standards. I think it's much greater than Java EE 5 or JPA. It's about really solving business problems.

Cable: I wanted to follow up with Dave and Rob's discussion about heterogeneity and the Java platform. I absolutely believe—I agree with Dave—that the Java platform is bigger than the JCP, the Java community is much bigger than the JCP. I would argue that the language and environment that people innovate on today to create new technologies, whether they're open or proprietary, is Java. Heterogeneity is something we have to deal with, but there is a cost associated with that.

I visit enterprise customers a lot, and every one of them in management complains about the fact that they have all of these available, downloading all of these open source technologies, rolling them up in their projects, and shoving them out into production. They don't know what's out there, they don't know what's running, and they don't know what or when Darwinism is going to kick in. I'm not personally seeing a lot of Darwinism in open source yet, and I'm wondering when it's going to kick in and when people are going to find that they're sitting in the enterprise with an unknown set of no actionable open source technologies that have suddenly gone the way of the dodo.

One of the responses that BEA has is to go with our blaming strategy, which basically says there's these best of breed, open source technologies that we're taking into our platform because we can then go to our customers and say for this set of technologies that we believe, or the community believes, is a certain bet, we can support them as a commercial vendor. That's getting a lot of traction, certainly with the management; they're breathing a massive sigh of relief that they have some way to get a grasp on the unhindered creativity.

Through the Back Door
Chappell: What you have just touched on there is a broader issue of SOA governance or a governance in general, and that exists whether you have standardized on a platform or not [and] the notion of developers building services and throwing them out there. Every time someone does that they're instantly putting their company at risk because they're out of compliance.

Cable: How many developers read the license when they click accept before the download? You know somewhere in clause 105 it could say…

Zilka: …you owe us all of your revenue…

Cable: …yeah, you owe us 99.9 percent of all of your revenue. Oh, "accept." Click.

Bostrom: Even if they read it, do they really…

Cable: …understand it?

Bostrom: They're not in a position to understand IT law. And who is? But that's the real problem. They could read this whole thing and still make a bad choice.

Bray: Having said that, with respect, the list of technologies that got brought in through the back door by developers and deployed against the wishes of IT without asking permission includes the personal computer, the World Wide Web, and Java! Okay?

Cohen: And the spreadsheet.

Milinkovich: And to be honest, managers might complain about the fact that these components were brought in without the managers knowing, but do they complain about the millions of dollars and months of development time they save them by reusing code as opposed to developing it from scratch? If you go too far down the path you're proposing you're throwing the baby out with the bath water, and there's lots of start-ups with lots of different technologies with lots of different ways to deal with the risks.

There are obviously benefits associated with open source; you're right, there are definitely risks, and there's lots of different ways sound IT managers can put procedures into place. Basically, what you're talking about I think is sort of the enterprises, which I would say are at stage zero of open source adoption, which is denial. In my experience there's fewer and fewer of those companies that are in that stage. More recognize [open source] is happening, and they have to do something about it. In most cases they can do it with clearer benefits that exceed the costs.

Cable: I think a lot of them are confused between free and open. There's very little free software.

Chappell: I think for an organization to achieve a level of maturity that it needs to be successful, it has to standardize on a certain set of platforms and technologies. Even if the platforms are open source, they have to standardize on something because you have to apply governance to the architects, the engineers, that are out there building this stuff to know what's going on with your technology.

Bray: But I repeat my thing; in history the IT has always tried to do that, the developers have always gone behind their back, and that's how we make progress.

Phipps: One thing to point out, Larry, is that I spent the last weekend at Devconf down in Mexico. The thing to note about the Debian system is that the way you go about assembling a system for deployment is completely different to the way that we've been used to in the past. We've been used to doing evaluations of software, which we then select and procure and then assemble. In the world of Debian, the way that you work is you assemble and then select and then procure.

What you're procuring is the services and support and know-how to keep what you've assembled in production, and what you're seeing there is a shift in the way that the market works. I think that what you're describing there with people acquiring free and open source software and then assembling it is an indicator of the way that the software development market is going. The question is not, how can we stop these people doing this? Or how can we control them? The question is more how can we, at the time we come to deploy the software, control our risk? How can we appropriately identify where to get the support and service from? I think those will be the questions that people will be asking in this world in the very near future.

Most   Popular