Java-Clone Announced
1. Everything we're doing in conjunction with M$ is Open Source.
2. All the extensions we're implementing are cross-platform - they don't just run under Windows as the WSJ article implied (okay, COM integration is a problem if you've got no COM on your platform to integrate with I'll give you that). If developers use Delegates they'll work on Linux (or whatever) and J/Direct is just another JNI-style interface anyway. We're looking at providing some Win32 compatiblity libraries for commonly used J/Direct Win32 library calls.
3. M$ have *not* invested in us - we approached them to about making Kaffe run both Sun and M$ Java and they paid for the work to happen - but we insisted that the result would be put in the Open Source Kaffe version so users had the choice to use, or not to use, the extensions.
Note that I have no connection Microsoft, Transvirtual, and don't even use Java very much. What follows is largely my own speculation.
First, let's go back to Visual J++. Let's ask ourselves what exactly were Microsoft's proprietary extensions to Java? First, they added stuff to the standard library to access native libaries, and second -- and this is the kicker -- they added some keywords to make writing COM objects much, much easier.
Now, let's hop back a bit, and look at MS's other language offerings. There are basically two of them: Visual Basic and Visual C++. It's really easy to use COM objects from VB; this is basically what COM is for. But if you want to write a COM server to componentize a program, then Visual Basic is entirely the wrong choice. It's just not fast, robust or powerful enough.
Which leaves Visual C++. However, MS has discovered that poor design has consequences that can't be patched over completely. It's sheer screaming agony to write those easy-to-use-from VB COM objects w/ Visual C++ -- all the wizards and templates in the universe can't change the fact that we are working with basically broken tools (COM and MFC and Win32 APIs, oh my). This difficulty is Bad News for MS; the more pain it takes to use Windows, the more likely people will look to alternatives.
This is where Java comes in. It has more OO nature. It has full garbage collection. It has no pointers. It is strongly typed. It looks familiar to C++ programmers. It has the hype machine of the century. And it's a different language, so you have a chance to leave all that old cruft behind.
Of course, there's that pesky VM and "write-once, run anywhere" promise, but if you can make it easy -- as seductive -- to call COM objects, then you are just as tied to the platform, because COM is Windows-specific.
Hence the changes in J++. (It also explains why they were so easy to turn off; they weren't out to encourage platform-dependence by making syntax changes, but with an easy hook into Windows. It cost them nothing to look like a good citizen by providing a single check-box off switch.)
Unfortunately, MS misjudged both the popular sentiment and how much Scott McNealy hates them, and they lost both popular support and part of the lawsuit. But not the important piece of the lawsuit -- they still have the right to use clean-roomed versions of Java.
This is where Transvirtual comes in. They have a GPL'd, clean-room implementation of the JVM. MS can pay them to implement the modifications to Java they desperately need -- VC++ is a dead end and they know it, and they need a replacement for it bad.
I'm betting that these changes will almost certainly be GPL'd. Why? This is because GPL'ing the changes to the Transvirtual's JVM is just good business sense.
It doesn't matter to MS if the COM hooks are public or not -- the lure to use Windows only is all the COM objects available for it, not the syntax.
GPLing the changes will buy you instant and total protection from charges of being closed and proprietary, because the GPL is the most anti-closed license there is. Plus, a JVM that is libre-free and MS-sanctioned JVM will most likely kill the market for competing JVMs on Win32.
Ok, folks, here are some facts on Kaffe:
There are two versions, the Open Edition and the Transvirtual edition. The open edition is GPL'd and other has a proprietary license. The code base of the two projects are totally separate. Transvirtual donated most of the code to the open edition, and continues to provide many updates. There are a few proprietary features that aren't availabe in the open edition (such as a DOS (?!?) AWT), but not many. People who contribute to the Kaffe open edition are not automatically contributing to the proprietary version. Only if you voluntarily decide to let Transvirtual use will it be included in the proprietary version.
Obviously I'd rather not see a proprietary version at all, but I think Tim Wilkenson has done a pretty good job of trying to find a model that lets him make money and contribute to the free software community as well. Originally, Kaffe was under a BSD license, and some people ripped him off by not releasing their changes as free software. He was planning on taking Kaffe proprietary as a result, but decided to release it as GPL instead. In this case, the GPL protects both the commerical interests of Transvirtual and the free software community.
So Kaffe will remain available as a free software product. If Microsoft hires TVT to write some Windows specific changes to it, these may or may not be released as free software, but this will not affect the main body of the Kaffe open edition code.