Unplugged interview: Sun software czar Jonathan Schwartz

In a recent interview, Sun executive vice president of software Jonathan Schwartz responded to a column by ZDNet executive editor David Berlind that questioned whether a recent collaboration by IBM and BEA could signal the beginning of the end of Java standards.

In the interview, Schwartz addresses the moves by IBM and BEA, the integrity of the Java Community Process, indemnification from liability as it pertains to Linux and open source, and how Sun plans to make it easier for enterprises to transition from Microsoft Windows and Office to browser and Java-based alternatives.

ZDNet: IBM and BEA recently teamed up to produce and support some J2EE extensions before getting them ratified by the Java Community Process (JCP). Is the JCP marginalized when two of its members, who happen to be market share leaders, get together to endorse J2EE extensions that the JCP hasn't had the time to consider?

Schwartz: I'm not sure that is orthogonal to the objectives of the JCP. The JCP is there to make sure that there's a standard across multiple implementations. It's also a place for defining the next generation of a JCP specification [Editor's Note: JCP specifications are known as JSRs or "Java Specification Requests"], but there are other ways to skin that cat. This isn't as much about the JCP as it is a response to our new application server.

ZDNet: By all measures, IBM and BEA are way out in front in terms of market share. What about the new application server do you think commands such a response?

Schwartz: Both IBM and BEA are under pressure from our AppServer 8.0 because it's free and deployable. It's both J2EE 1.4 and WS-I Basic profile compliant, and you can run your business on it. It's available on Solaris, Linux, HP-UX and Windows.

ZDNet: It's completely free on all those platforms? No strings attached?

Schwartz: No strings attached. It's also nice to see JBoss signed up as a licensee. So, between us, JBoss and Apache, IBM and BEA are going to have a hard time charging the marketplace tens of thousands of dollars per CPU. That pressure is what motivates IBM and BEA to innovate.

ZDNet: But why announce the extensions before taking it to the JCP instead of after the fact?

Schwartz: [IBM and BEA eventually] submitted them to the JCP because the market looks to the JCP for the standards they deem safe. Because of the standards, the JCP enables substitution [of one standard compliant application server for another] which in turn causes competition between application server providers. I know that frustrates IBM, who would prefer to partner with Microsoft in the Web Services Interoperability Organization (WS-I), but that appears to be stalling out.

ZDNet: Why do you think the WS-I is stalling out?

Schwartz: I haven't seen it getting a lot of traction in the marketplace. There was a point in time where Java and Web services were orthogonal to each other. Now they're synonymous with one another. Additionally, Microsoft is doing a lot more outside of the WS-I, focusing on efforts that are more strategic to Windows, such as the evolution of Longhorn and their application server infrastructure. It's all about driving Microsoft, not the WS-I. So, right now, there's only one cross-platform organization driving Web development, and that's the JCP.

ZDNet: IBM has complained before that the JCP moves too slow. Could the way IBM and BEA worked on these specs first, and proposed them to the JCP second be a response to that issue?

Schwartz: IBM and others accuse the JCP of being slow. That's a cynical interpretation. The JCP is slow to IBM because IBM wants to deliver proprietary technologies and wants to do so under the veil of a standard. They claim that waiting for and complying with standards slows them down. Meanwhile, if speed were so important to them, wouldn't they have shipped a J2EE 1.4-compliant version of WebSphere sooner than they did? We were the first to ship a 1.4-compliant server that also had support for the WS-I's Basic Profile. We even had WS-I Basic Profile support before Microsoft did. This is evidence that the JCP is faster than the competition that IBM consistently and unfavorably compares the JCP to. [Editor's Note: Schwartz wasn't specific about which organizations he was referring to. For the most part, IBM's Web services-related industry collaborations turn up in the WS-I or the Organization for the Advancement of Structured Information Standards, OASIS.]

ZDNet: How soon after the specification was released did you release support for J2EE 1.4?

Schwartz: I think we were out with it on the day it was approved. If not, it was very shortly thereafter.

[Editor's note: Under the auspices of a developer's technical preview, IBM released a J2EE 1.4-compliant and WS-I Basic Profile-compliant application server last month. Sun released a developer's edition of its J2EE 1.4-compliant application server in the second week of November 2003, approximately one week after the JCP's final balloting process for the J2EE 1.4 specification was completed on November 11. Two weeks later, on November 25, which was also the day after the Final Release of JSR 151 for J2EE 1.4 was posted for download on the JCP's Web site, IBM and BEA announced their mutual pre-JCP support for three J2EE extensions that they co-developed.]

ZDNet: Who currently has support for the J2EE 1.4?

Schwartz: Just us and IBM.

ZDNet: How long will it take for the three extensions that BEA and IBM proposed to the JCP to run their course?

Schwartz: That's up to the JCP. There's no competitive agenda within the JCP. The only agenda of the JCP is to guarantee customers that the standards they rely on will give them the flexibility they want and while providing them a way to avoid any proprietary lock-ins. That's why developers have to avoid proprietary, vendor-specific application server APIs that aren't recognized by the JCP.

ZDNet: What about Eclipse and the way that IBM is sitting out of the recently formed Java Tools Community?

Schwartz: There's a lot of skepticism about IBM's intent. This is why Eclipse is viewed with skepticism. It's really about driving WebSphere.

ZDNet: What is it about Eclipse that Sun finds so disagreeable?

Schwartz: IBM uses Eclipse to tie developers back to WebSphere and a non-standard GUI library for Java called SWT. It's not as portable as SWING, which is the standard. It's very clever and they've done some nice stuff.

ZDNet: But can't developers write to SWING with Eclipse if they want to? It's not like Eclipse prevents them from going with the SWING standard.

Schwartz: That's true. You can write to SWING if you want to. But the tool is not as graceful when developing for SWING as it is with SWT. The same thing goes in terms of writing to IBM's WebSphere as opposed to just the standard J2EE specification. That's why we introduced the Application Verification Kit (AVK). This allows customers to take their applications and run it for free against a reference implementation-- our AppServer 8.0-to see if they'll get caught by any proprietary APIs.

ZDNet: What happens if it encounters any proprietary APIs?

Schwartz: It throws up errors and says these specific lines of code represent risks to that application.

ZDNet: Let's switch gears to Linux, SCO, and indemnification. Last year, you were one of the first ones to raise the indemnification issue. You were questioning how companies could move forward with such a potential liability and pointed out how Sun was willing to offer indemnification. But as it turns out, that wasn't for Linux, but for Solaris. Now that your strategy involves a lot more Linux than it did before, has Sun's position on indemnification changed at all?

Schwartz: Today, if you run our desktop-the Java Desktop System (JDS)--we'll indemnify the entire solution.

ZDNet: What version of Linux is that based on?

Schwartz: Right now it's SuSE's.

ZDNet: Will Sun ever have its own distribution of Linux?

Schwartz: We're always on the lookout for opportunities to keep costs down for users. Right now, we have no big motivation to change. The deal with SuSE is good. The one company that's interesting is IBM. IBM is the largest intellectual property litigator on the planet, yet they refuse to indemnify their Linux customers.

ZDNet: HP is a lot like IBM. They ship Linux with their gear but it's not the company's own distribution of Linux. Even though HP is an integrator, it's willing to indemnify. How about Sun? Like HP and IBM, Sun is an integrator. What about people who run Linux on your gear?

Schwartz: We indemnify when we produce an integrated solution, like JDS. But, for a server, where someone is running Red Hat Linux for example, they need to turn to Red Hat. We like to see Linux vendors indemnify. If you can't stand behind your intellectual property, then what value are you bringing to your customers? Have you seen Red Hat's 10-Q filings recently? Look at how the risk factor section in its filings keeps growing. So, we'd like to see Red Hat indemnify along with HP and Novell.

ZDNet: Does Sun have any other plans for indemnification beyond JDS?

Schwartz: The Java Enterprise System is a possibility.

ZDNet: That's on Linux?

Schwartz: Linux support is coming. Right now, it's on Solaris. We're looking into indemnifying.

ZDNet: As a moonlighting developer who is relying on Office, Outlook, and Windows APIs to do a lot of the heavy lifting, I'm wondering how I might accomplish the same thing in Java. However, Java has no access to those APIs. Sun sued Microsoft, which essentially shut down that access. That not only cuts off my opportunity to move to Java (unless I go completely cold-turkey), but also to smoothly transition off of Office or Windows if I chose to do so. How are you going to move customers from Office if there's no access to those APIs or abstraction layer between MS-Office and StarOffice to facilitate that transition? In hindsight, maybe the pathways that Microsoft originally provided were a good thing.

Schwartz: You want write once, run anywhere. One of the problems with Microsoft is that the idea of write once, run anywhere and the opportunity to transition customers doesn't materially exist. But now that we've shipped the Java Desktop System, we've seen a tidal wave of interest in porting applications to browser- and Java-based environments--all of which we've already done here at Sun. As a result, while the rest of the world gets to enjoy [the MyDoom virus], we are untouched at Sun, and we are running the same types of productivity applications that we would otherwise run on Windows. For companies that feel like they can't bear the expense of recreating those applications, they should take a closer look at the Java Enterprise System. One of the reasons we priced it at $100 is so that enterprises can save millions of dollars, use some of that money to cover the cost of migration, and still have plenty of savings left over to spare. But in terms of providing a transition path, what customers want is to be able to securely transition to a new and more secure environment. So, we're looking for ways to provide access to the [Windows and Office] class libraries in the Java Runtime.

You can write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.