... unless Sun's code is really well written.
Isn't this a little bit arrogant ? and self_flattering (forget my grammar) ?
Well, I've seen Kaffe's old class library, and I've seen GNU Classpath, and I've decided to move Kaffe gradually over to use GNU Classpath, because it is really nicely written, and more maintainable. I have no idea how well written Sun's class library is, but I know from experience maintaining Kaffe's runtime class library implementation now that class libraries may be not very maintainable, even though they work, essentially.
GNU Classpath hackers have a rather high standard, and they will flat out reject patches that do not meet it. I know, I've had several patches rejected and had to fix them till they passed the public mark of approval. I have no knowledge of Sun's practices in that area. Given that they are dragging a code base with them since Java 1.0, I'd assume that some areas have accumulated some cruft, that GNU Classpath does not have, as we have the liberty to write the implementations from scratch and to write them nicely.
... if a community of free software developers can write a better implementation from scratch in less time, for example.
you know that things are completely different in reality.
I've seen some very capable people start from scratch and implement a major deal of Swing over SWT in less than a year. Classpath Swing was almost non-existant a year ago, now large chunks are done and work. It takes really good, motivated developers to change things. Fortunately, there is no shortage of really good, motivated developers in reality.
Quality of implementation and freedom are the two things that really count, in the long run.
Look. How about being sure one thing runs on another platform when it is told that it does ? How about *me* doing *nothing* to ensure that ?
You wouldn't believe that Sun's runtime code has some magic property that makes it portable accross platforms without testing , right? :)
There is a marketing fantasy that writing programs in Java automatically makes them portable. That is not true, even among Sun-derived implementations. You still have to know what the grey areas of the language and API specifications are. They are different from C, and C++, sure, but they are still there. Java memory model, floating point semantics, blowing up the stack through serialization, different side-effects of file handling, etc.
Cross-platform comes with the price of writing cross-platform code. Java is nicer than C or C++ in that respect, by coming with larger a class library that largely behaves the same on many platforms. It's still not very hard to shoot yourself in the foot, though, depending on the task.
Yes I am talking about guaranteed easy to use. I don't want to go through the 'make' hell or whatever you have to pass when working in the c c++ world whan wanting to deploy on 3 different os-es. Yeeees I am a lazy person, I like what Java does in this space for me. I don't care what you think, I don't care that you feel good being a hacker but my first concern is now *meeting my customer's needs* not hacking through an open source java impl to make it work on every targeted platform.
That's easy. If proprietary VMs are good enough for your tasks, please keep using them. If they are not, feel free to look around for alternatives. If you need guarantees, and 'professional open source'-like support using the alternatives, feel free to hire some professionals. If you don't need that, even better.
Kaffe is not Java(TM). Neither is GNU Classpath. Free runtimes are not a seamless, drop in replacement for the JDK. Whoever wants to sell you seamless, drop in replacements for other people's software is selling you snake oil. Not even Sun's JDK updates are seamless, if you read their nice compatibility documentation. So if you are a lazy person, you stay with what you have, till the costs of staying lazy outweigh the gains made by switching. Remember, you don't have to use free runtimes, you can use them if it helps you do what you need to get done.
In any case, I don't see everyone switching to the Java 5.0 language right now, so I think GNU Classpath will be able to catch up in one or two years for most developers' needs.
How about ALL developer's needs ? I __can_see_it_happening__ with James's ideea. Of course if there are stil guys in your camp that would think that Sun's implementations worth shit and get rid off their pride to write those by themselves and just take some working pieces of code and use them.
'Working' does not imply maintainable. As I said before, I've seen some working AWT implementations in Kaffe, that were essentially unmaintainable wihout some major refactoring. I don't know if Sun's imlementation is good or not, I can't judge without access to the source. But knowing what I know from switching Kaffe to use GNU Classpath from our own class library, I can say that GNU Classpath is a very nicely written class library, but that in any merge, you'll find code that's been written better in one implementation than in the other. Quite often, you'll find that both implementations expose problems in each other. That's the reason why we are switching gradually to GNU Classpath, it allows us to fix things that weren't noticed before, because the code was 'working'. By taking 'working' code and putting it into an 'alien' environment, we are able to detect new problems, and fix them. That process is making GNU Classpath stronger.
See, I'm not aware of anyone being able to legally do that with Sun's code. So I'd expect it to be a mess, from my experience with some OpenOffice Java libraries I've seen. The mess comes from the code not being under public scrutiny, so there is no need to make it work in alien environments, there is noone rejecting dumb patches, etc.
To put it simply, 'working' code is not good enough for GNU Classpath. It needs to be 'working and well-written', because we'll be stuck maintaining that code for years. And we'll be taking that code to where no Java code has been before.
Please also note that I'm not saying that all of GNU Classpath's code is superbly well-written. For example, Jikes 1.21 spews out a ton of warnings compiling the class libraries. But those areas where GNU Classpath is sub-par, we can fix, because they are out there in the open, and other developers can help us make it better. That tender, love and care GNU Classpath receives from various participants is a crucial long-term advantage it has over Sun's class library: it has a community of people wanting to make it better. And that's what matters: the long term.
Sun is more than welcome to join in the fun, and put their code on the table, of course. It would be nice if they decided to contribute their libraries to GNU Classpath, sure. Hey, I'd be glad to merge in some GPL-compatible ORB into Kaffe, and if Sun would want to make that easier by contributing theirs, sure.
But that is not going to happen, no matter how many open letters get written by anyone. Sun has been repeatedly asked, at least since 1996[1], to open up their code, or to at least clear up the legal ambiguities surrounding Java. They have refused to listen. Sun knows very, very well what 'open source' means. And they do not want it for their Java(TM) implementation. Period.
So if you want an open source runtime, forget about begging Sun to put one in your lap. That's a waste of time. Don't write open letters. Do what you do best: code.
As a side note: you can never write non-trivial software that makes everyone happy. There is always some area where you need to make decisions, and decisions mean that you pick between alternatives, leaving people who would have preferred the other alternative to do their own thing. That's life. Sun's class libraries are not making everyone happy, either, judging by the bug database. That's normal. The difference is that with free software you can actively do something about it, while with non-free software you are at the mercy of your vendor.
They will never open source Java in the way the *mustache* wants it so a compromise seems the best move.
The fundamental issue is freedom. If that's the case, it would be pointless to make compromises on freedom. It's simple: Sun does not want to give you the freedoms of free software with their implementation. There is nothing in it for them if they free it up. Free software developers, on the other hand, have no incentive to give up their freedoms in order to make Sun happy.
If it's not enough to determine Sun to look into it and make it happen than some from Jakarta's chair should take ObjectWeb and any other OS java initiative by hand and make an open letter or something. At least we would get an answer to that.
They've looked into it. Actually, his proposal is not radically different from what ESR or IBM proposed. Sun rejected that. Various people have written open letter with zero effect. Open letters are a waste of time. They have not worked in the past, there is no reason why they should work now.
As long as Sun's has no competition in the 'cross-platform' field, that's not going to change. Fortunately, there is Mono, Python, DotGNU and Perl6 to give Sun some things to think about what went wrong, say, 5 years from now. I'd expect Sun to open source their legacy Java(TM) technology around 2010, not earlier. But then of course, Java(TM) will not matter much to anyone in 2010. It will be no different than the opening up of old Unix code by Caldera or of some old compilers by Watcom.
If you want a different future for your code, like I do, you know where to look.
cheers,
dalibor topic
[1]
http://www.javaworld.com/javaworld/jw-09-1996/jw-09-javaqa.html