Will You See Open Source J2EE Implementations? Not Likely.
by Mike Loukides02/13/2002
Editor's Note: O'Reilly & Associates' senior Java editor Mike Loukides revisits Sun's positioning on an open source J2EE and its effects on JBoss and other open source J2EE projects.
I wrote "Will You See Open Source J2EE Implementations?", about four months ago, at the end of September. Not much has changed since then. Sun still hasn't certified JBoss, and persists in saber-rattling to scare off others who might want to do open source implementations of J2EE technologies. At the same time, Sun loves to have Kodak moments with some parts of the open source community -- most notably, Apache -- who increasingly feel used and abused.
The Apache group has made a number of suggestions for changes to the terms on which members participate in the Java community process. I won't go into detail on these suggestions, but two are extremely important to the continued success of Java. First, Sun cannot continue to have licenses that prohibit compatible open source implementations. That sort of control is probably indefensible legally, and it's certainly offensive to anyone who is interested in developing open software. Second, Sun needs to make it easy for nonprofit groups (including open source and academic groups) to perform compatibility testing. The current situation, in which compatibility testing is prohibitively expensive, is not fair, not in the interest of the Java community, and not even in Sun's interest.
One thing Sun could do to push Java's acceptance forward would be to release the compatibility kits to the open source process. That would reshape the Java market in interesting ways. It would require Sun to give up some control -- but practically speaking, this loss of control would be minimal, since the JSR specification lead is responsible for the official compatibility test kit. I'm sure that Sun worries that an open source compatibility test would risk splintering Java into different camps surrounding different compatibility definitions. But with the JSR spec lead in control, that's unlikely to happen. The open source communities have been extremely good at preventing their standards from diverging -- there are no incompatible implementations of Perl, of Ruby, of Python, or of any significant tool that I'm aware of.
Furthermore, open source compatibility kits would make compatibility testing even more rigorous: you'd have BEA developers testing IBM's products, finding the incompatibilities, and submitting tests for inclusion. You'd have IBM developers testing iPlanet. And so on. All of these tests that break competitor's implementations wouldn't necessarily be included in the official compatibility test, but the open source process would get these incompatibilities on the table, making it possible to discuss intelligently what compatibility should really mean.
I don't think Sun will take a step this bold, though it would be in everybody's interest. But we can call on Sun to establish a level playing field in which all Java developers, regardless of their funding or licensing requirements, can participate. Simply put: JBoss is an excellent piece of software; it's one of the best J2EE servers around, at any price. If JBoss is not compatible for legitimate technical reasons, fine. But if JBoss can't be certified because Sun won't test it, then certification is meaningless.
Mike Loukides is a senior editor for O'Reilly Media, Inc., with a focus on developing titles on Java, UNIX utilities and system administration.
Return to ONJava.com.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 8 of 8.
-
The open source communites aren't as perfect as all that
2002-03-07 17:16:55 jonadab [Reply | View]
> The open source communities have been extremely
> good at preventing their standards from
> diverging -- there are no incompatible
> implementations of Perl, of Ruby, of Python,
> or of any significant tool that I'm aware of.
Hello? Surely you are not unaware of XEmacs?
If that isn't an incompatible implementation
of a major tool, I don't know what is, and both
implementations came from the same codebase,
which was (and both still are) under the GPL.
People with conflicting interests and ideas
will always be able to create incompatibilities,
regardless of what licensing model is used.
(This is not to say that I agree with Sun's
position, only that open source licensing is
not such a potent magic that it can rid the
world of problems.)
-
Java and DotNet
2002-02-17 17:44:26 tobyhede [Reply | View]
I personally see Open Source Java as a crucial response to MS and DotNet. I know this is a really dangerous and conteitous area, but it is not my intention to start a flame war...
MS has leveraged the experiences of the Java communty in creating DotNet and as such it makes certain advances in technology that provide a compelling business case. Visual Studio .Net is also now the most advanced IDE available. I don't think this point is really worth arguing, I simply concede it...that said, Java WILL catch up, and in some places it probably is still ahead.
The result is that the business case for J2EE has suddenly become a much harder sell...there are of course a subset of incredibly large software systems that will remain in the Java world regardless, but I would argues this isn't necessarily driven by Java so much as the integration support and services these systems demand from vendors (this is where we still find companies like IBM).
However, the whole middle ground of enterprise development has compelling reasons for choosing DotNet, including lower costs in terms of up-front costs (notice: this is not necessarily TCO, but up-front costs play a crucial role in times of tight cash flow (conomic downturn, anyone).
Open Source provides a crucial role here. Many companies that run JBoss today will demand aan IBM, BEA or Sun system tomorrow. Application Servers are also obviously becoming much more 'commodity' driven market segment and has been observed elsewhere repeatedly, Open Source functions very well in this type of market.
Sexy tehnology coupled with the MS marketing machine means that J2EE has lost significant momentum recently. Remeber that the real issue here is the platform, not the language or the implementation, but the services and framework that together make up the entire J2EE platform. Platforms benefit from network effects, and this is something that MS has always known (in fact their entire business is based on this principle and I would bet that MS will ensure that DotNet is installed on every capable Windows machine within the next 12 months). The crucial point is to spread the platform as widely as possible, even at the cost of immediate revenue losses...Open Source J2EE is the answer here, this would create a groundswell of smaller Java installations, really pushing the platform. It aslo provides a fertile learning area for future developers and architects. It is obvious that many developers cut their teeth in Open Source before moving into the commerical world. This is simply a result of availibility and the reason why development versions of so much software is free or cheap these days.
Sun has also been reluctant to adopt web services, largely I think because it really goes to the heart of Sun's hardware business...Web Servcies provide an alternative paradigm to the Big Iron appraoch to centralised server systems.
The JBoss vision of the 'WebOS' provides an excellent model for the Web Service world. Small ubiquitous app servers, deployed to the edges of the organisation providing needed services as close to the requirment as possible. Unforntunately, this is a really decentralised approach that really coincides with a MS vision (sell more Wintel boxes) than the enterprise incumbents (sell one BIG box).
MS has been pushing the CLR and language independence heavily within academia and is gaining some significant support in this crucial realm. With Sun vacilating over opening core components of the Java platform, it becomes a key issue in research terms.
NOTE: the real issues here are not whether DotNet is technically or idealogically better than Java, but in relation to marketing, user base and ubiquity.
-
Yes, Open Source J2EE will happen!
2002-02-15 13:51:57 guncarbone [Reply | View]
However, open source will probably never be able to use the "J2EE" brand. Sun generates revenues from this branding and is likely very reluctant to give it up. So we'll have projects like JBoss.org or ObjectWeb.org that have J2EE implementations, but not officially be J2EE.
Will that matter? Will a label stop developers from realizing that an open source implementation is really J2EE? Not a chance. Open source succeeds when it does things right, not because it has some label attached to it.
-
Ask to Sun
2002-02-15 11:50:50 ppesci [Reply | View]
I love open source and want to contribute as many others i think, but open source is not the best choice in every case.
Microsoft tryed to kill java using a windows dependent extensions that become in incompatible implementation versions. If Java was open source, this tactic was good, but Java is not an open source and Sun has lawers. The rest is history...
At last, not all is perfect but has been good enough because you wrote this article and I'm writing this comment. Java is alive, don't agree?
Can you do a really BIG favor to us?
Ask to Sun if:
1) Open source don't be certificate because is open source.
2) Open source don't be certificate because certification is a paid process.
If (1) is true, that is bad news for all of us, Sun included.
But if (1) is false, (2) is true, and then O'reilly can lead a movement to collect the funds for in example, JBoss certification, and if O'reilly does, me and many others will contribute i think.
We don't want to waste my investment in O'reilly Java books :).
Can O'reilly be in the solution side of this problem?
Pietro
-
Sun says one thing; does another
2002-02-14 11:31:14 Steve Anglin [Reply | View]
What's interesting to me is that Sun, especially Sun's VP of Java Software, Richard Green, says that Sun wants to be the Java "evengelists" for the Java, XML and Web services software industries and its vendors. In other words, they really say they want to be the '.org' for Java. In contrast, their actions speak '.com', as outlined in this editorial.
-
Have you actually used the J2EE CTS?
2002-02-14 03:53:04 pierce [Reply | View]
First up, I've used the J2EE CTS - the notion of "BEA developers testing IBM's products" is broken. Every vendor must develop a porting layer to hook their product into the CTS, this porting layer generally contains internal API knowledge. Vendors are not required to make this layer public (and I'm certain they'd be unwilling to do so).
Secondly, the CTS only tests behavior and API conformance, it is not an exhaustive system test suite. Yes, there aree thousands of tests, but it's no silver bullet for J2EE testing.
Third, involvement with CTS generally needs backup from Sun's licensee engineering organization, this service costs money for Sun to provide. If OpenSource groups want to be involved in J2EE confirmance they can pay for the service.
Fourth, I've meet the Sun J2EE and CTS folks, I believe that Karen Tegan's response is being misinterpreted - "having a strong brand and compatibility standards are important ... The J2EE Compatible brand has achieved siginificant momentum overt the past two years, and we want to make sure that any open source efforts don't impact the viability" - my understanding of this statement is that it is not an attempt to exclude OpenSource projects, on the contrary, it is Sun expressing the hope that OpenSource efforts do not weaken the "J2EE Compatible brand" by claiming conformance to J2EE when they may not be (conformance is decided by sucessfully passing the complete J2EE CTS).
http://www.jboss.org/
http://incubator.apache.org/projects/geronimo/