How to open source Java without sacrificing compatibility

I came up with this idea while still the CTO at BEA Systems. While I haven’t gotten any bigger takers yet, it still seems immanently workable to me.

Being a server-side Java guy for going on a decade, I would love to see a bit more of the open software community’s efforts focused on Java. Vendors like Microsoft appear to me to be making relatively bigger investments in managed code (with C#) than we in open source land (with Java). With the launch of Apache Harmony, I think we’re making progress, but more can be done (like making Java the heart of Mono?).

My modest proposal: Open source the existing Java language implementation—J2SE (Java 2 Standard Edition) including the virtual machine and developer kit—such that any redistributed derivative works must either (1) pass the appropriate TCK (Technology Compatibility Kit) and hence be certified as Java compatible; or (2) assuming they fail to pass the TCK, then such derivative works are precluded from using the Java brand or the Java namespace! The latter, of course, is the big hammer. Developers are already very careful to monitor what packages they are using in their applications: they rightly ask is the package Java standard and hence in a Java namespace, or is it proprietary? Not wanting to suck in non-Java packages would create, I think, exactly the kind of stick the Java community is seeking to enforce compatibility across Java implementations. For example, C# technology is actually quite a bit closer to Java than is perceived in the industry, at least in part because of the gap created by differences in brand and namespace.

Of course, this approach would require open sourcing the Java TCKs as well as the virtual machine runtimes and developer kits, and so Sun and other TCK owners would be deserving of some compensation for doing so. Of course, moving to an open source model would allow more of the burdens of advancing Java to be shared across the community, thereby cutting costs at Sun and the other Java stakeholders. More importantly, this could enable a world in which compatibility gets better—i.e., more self-policing—as developer’s check in tests that highlight ambiguities/differences between Java technologies.

Open sourcing Java in this way would also require a new open source license, but the prospect of bringing in Java would presumably justify the investment in OSI approval.

My $.02. –Scott (The Blind Stupid Optimist)

p.s. The following discourse actually took place during a Java Community Process Executive Committee debate.

Scott: “Blah, blah, blah, …”
An opponent in the debate: “And just why do you think that would work?”
Scott: “I guess because I’m a blind, stupid optimist.”
A much smarter ally: “Scott, I sure hope you don’t loose your optimism, ’cause then your just going to be blind and stupid!”

Comments are closed.

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures