Slashdot Mirror
Java-Clone Announced
Thomas Charron wrote to us with the latest Microsoft-Java
">news. Transvirtual, a "closely held start-up funded by Microsoft" has cloned aspects of Java. This new software called "Kaffe" will let programmers write Java that will run only on Windows. What's interesting is that on their homepage, Transvirtual seems committed to working with the Open Source idea - partnering with Cygnus. Does anyone have details clearing up these seeming contradictions?
Update: 06/14 08:51 by H : Click below: Tim Wilkinson from Transvirtual e-mailed me. Here's the salient points: Everything they are doing with MS is Open Source, and runs all platforms it can, and they are not funded by Microsoft. They were incredibly misquoted by the Wall Street Journal.
1. Everything we're doing in conjunction with M$ is Open Source.
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.
----------------------
News about the "Open Source" Kaffe distribution
can always be found at:
http://www.kaffe.org/
and also at:
http://www.transvirtual.com/
And mailing lists? ...
------------------
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.
Yes, but the information regarding Kaffe DIDN'T take into consideration that Microsoft bought up a good hunk of Transvirtual. They are now in a position to use Kaffe, NOT release the source, and 'choke and kill' Kaffe.. Heck, they may starty to pollute the Kaffe source, as they 'own' the major developers..
I think the developers hearts are in the right place, but I think Microsoft is going to screw them in the long run, and hopefully not Kaffe in the proccess..
Heck, this COULD be the case that blows the GPL out of the water, if the developers and Microsot ever come to heads..
-- I'm the root of all that's evil, but you can call me cookie..
Kaffe is a GPL'd jvm (yes it IS a java virtual machine, not "cloning some aspects of java", its just a clean room implementation) that has been available on tons of different platforms from the beginning. Transvirtuals web page even says so. This doesn't make anything java related run on windows alone or any platform alone for that matter. Journalists just obviously don't know the meaning of research anymore....
I don't know about Microsoft's involvement, but it has been clear for a long time that Microsoft resents Sun's dominance in the Java world. I'm sure they'd be happy to have a non-Sun-controlled JVM. Whether or not they care enough having a non-Sun-controlled JVM to fund a GPLed development, I don't know.
Sun's control of Java was predicated on the idea that nobody else was smart enough to write their own. They should have known better. Someone else did, and now Sun has no way of keeping MS from putting in their own incompatible extensions.
About Transvirtual's being a tightly-held MS-funded startup, well, maybe now, but they've been releasing free software for two years or so. I suspect that the article is seriously garbled on this aspect.
Thanks
Bruce
Bruce Perens.
"Java that will run only on Windows"
.kaf (or whatever) files too.
.java extension just to sow chaos and confusion, as part of their usual "purloin and pervert" (uh, "embrace and extend") tactics.)
An oxymoron. There's no such thing. If it only runs on Windows, then at best it's a "Java-like language". I wonder if the next "Explorer.Worm" targets
(Although MS will probably stick with the
-- Alastair
The Kaffe that's already out there under GPL is available to anyone and will continue so. New versions don't have to be GPL'd, however.
Given the above concerns about Microsoft and Transvirtual, it may be time to fork the tree (or be ready to) and proceed with Open Kaffe (GNU Kaffe? some other name?) independantly of whatever MS/TV do.
-- Alastair
I read the update. It makes things seem even worse, not better.
Without the clarification, we could at least hope that the MS crap would remain confined to the TV's proprietary JVM, and the open one would remain pretty much conformant to 100% Pure Java.
Now we see that the open version is being seduced to the "purloin and pervert" (embrace+extend) side of the force.
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). That's hardly cross-platform, then, is it? If developers use Delegates I don't recall those being part of standard Java they'll work on Linux (or whatever) and J/Direct is just another JNI-style interface anyway. Which we need....why? We're looking at providing some Win32 compatiblity libraries for commonly used J/Direct Win32 library calls.
Oh, joy, more Win32 crAPIs. And they'll work just how on end-swapped or 64-bit word machines?
The GPL'd Kaffe tree is about to become hopelessly contaminated. Somebody fork it now, please!
-- Alastair
I program in J++ and I chose J++ for the following reasons:
1. It's an object-oriented language which is better for writing visual user interfaces.
2. Java does not have segmentation faults and bus errors which can bring a Win95 machine to it's knees (No comment on MS's crappy VM that crashes...but anyway)
3. I knew Java.
4. I THOUGHT that J++ was going to be _almost_ platform independent implementation of Java. I read many articles on J++ and did not understand that all of the generated code contained these STUPID function pointers...I mean delegates that MS demanded. None of the articles that I read pointed out how the generated forms (like Java Frames) work.
5. The Windoze window manager and ODBC (i.e. WFC) is called directly as opposed to being called through an additional layer, thus it (should be) is faster than going through java.awt.* AND there may also be a MS JIT compiler.
What I've realized since I've first started using it is that:
1. It would be almost impossible for me to port my applications anywhere, even with the many precautions that I've taken to keep MS specific code segregated in classes from platform independent Java only classes.
2. Because of the unnecessary inclusion by MS of their delegate class, all of the generated code for forms is completely unusable save a conversion utility (which does not exist) that could turn delegates into inner classes.
3. Programs run pretty fast after being compiled as compared to normal Windows apps.
4. If I had to port any of these programs to Pure Java, I would have to rewrite the lowest level database class and all of the user interface classes (what MS calls forms).
Why not C++?
C++ programs cannot be developed as quickly and take much more care. They run faster, but that is not what I needed--I needed rapid development.
Why not Visual Basic? Gimme a break! You call that a language?
The point of J++ and any other Windows dependent Java clone is to make the cost of moving from Windows too great for people to switch to another OS.