What's in a Name?
Posted under Java ·Maybe I’m naïve or too willing to give up my freedom, but I don’t really get the protestations about Apache’s ability to achieve Real Java™ Certification. Why is it so important that a free JVM implementation be able to call itself a Java™ Virtual Machine? Why did “…Apache [have] to fight to allow any Open Source implementations of JSR specifications”?
The JLS and the JSRs are not trade secrets, and—to my knowledge, I’m not about to go looking—most of them are not patented either. If I felt like punishing myself I have no doubt that I could spend a few years and a few million dollars re-implementing Java EE 5 and release it to the world without paying a cent to Sun or anyone else, and without worrying about a lawsuit.
Wait, what’s that? I wouldn’t be able to call it a “Java EE” implementation without paying for the conformance tests? Gee, that’s too bad. Oh well, I guess I’ll have to compete on the strength of my implementation and fabulously expensive marketing blitz.
How many people really care whether MyFaces can legally call itself an implementation of JavaServer™ Faces? If I used JSF, I would care that it implemented as much of the JSF API as I needed and was of high quality.
Similarly, I really don’t think the vast majority of developers could care less whether any particular JVM implementation is blessed by Sun, especially not when OpenJDK is available and IBM and Oracle seem happy enough to keep working on their JVMs.
What’s really important to me (and, I suspect, to most Java-ecosystem developers) is that, for the foreseeable future, there will continue to be a stable, high-performance, Java memory model and bytecode-compatible, scalable, manageable, cross-platform runtime for me to develop and deploy my products on through their expected 10+-year life cycle. That runtime really should be open source, and ideally there should be more than one compatible implementation—competition and choice are good.
I think most people would agree that we’re in pretty good shape here: all three major commercial JVM implementations are stable, performant, manageable, scalable and cross-platform, at least one of them is open source already, and the others are available free of charge (although not necessarily redistributable).
I don’t begrudge Sun their Java™ business model. They invest heavily in the Java ecosystem, have open-sourced one of the world’s most important pieces of software (in the form of OpenJDK) and should be free to dictate the terms under which their trademarks can be used. Those who care about certification can pay for it; those who don’t are already getting a whole lot of something for nothing.
Updated: Changed first sentence slightly to reflect that Stephen Colebourne is not speaking on behalf of the ASF.
- Thursday March 26, 2009
- 4 Comments
- Previous Article
- Next Article
1 · Aaron · Thu Mar 26, 09:50 am
Actually, by developing the technology outside of the JSR and without using the TCK, you could open yourself up to lawsuits and not just due to the naming. First off, not only can you not claim that your implementation is “Java” (or whatever) but you can’t even claim that it’s compatible with Java. Finally, the TCK gives you a patent license which is important with respect to the language specification.
This may all be FUD and you may be right, but you still place yourself, your code, and your users in a tenuous situation by not using the JSR and TCK.
Finally, of course plenty of people care if you can pass the TCK and call your implementation compliant! Who would be willing to risk your production systems using potentially non-compliant software?
2 · Alex Cruise · Thu Mar 26, 10:34 am
Aaron, I agree that patents have the potential to be a very dangerous aspect of competing with any offical Java implementation, but in practice I just can't see Sun suing anyone for doing what dozens of other projects are already doing. There have been encouraging signs of sanity at the USPTO with respect to software patents, so I'm hopeful.
As for the naming and trademark issues, they're very easy to work around, and anyone that cares whether their particular implementation is officially compliant can feel free to choose—or even pay for—one that is.
Who are we to insist that Sun must open the door to competing implementations that are free of charge and officially compliant? It would be nice—I use Java and don't like paying for stuff when I don't have to—but I don't think it's realistic or fair to demand it.
3 · Stephen Colebourne · Thu Mar 26, 11:41 am
“Who are we to insist that Sun must open the door to competing implementations that are free of charge and officially compliant?”
The $cost isn’t the issue here at all. Sun agreed back in 2002 that groups like Apache could implement JSRs and have $free access to the testing kits – http://marc.info/?l=apache-announce&m=105712416208947&w=2 . The problem is that Sun isn’t holding up its side of the bargain.
“Why is it so important that a free JVM implementation be able to call itself a Java™ Virtual Machine?”
This is sadly the wrong question. The problem is all around the IP and patent restrictions. Apache cannot ‘just release’ Harmony, as that would be in violation of the same agreement that Sun are currently violating. The IP and patents are only granted once the code is tested using the testing kit.
4 · Alex Cruise · Thu Mar 26, 04:57 pm
Stephen, thanks for taking the time to comment.
I have very little interest in discussing the terms or compliance of whatever contracts the ASF and Sun have entered into. My main point is that, given the current state of the marketplace, we, as JVM developers, don’t have much to complain about.
Now Java developers, on the other hand… Well, you probably know my position by now. :)