Slashdot Mirror
ESR's Open Letter to McNealy: Set Java Free!
yukster writes "Eric Raymond has posted an open letter to Sun Microsystem's Scott McNealy asking him to 'Let Java go.' He says Sun can 'have ubiquity or [it] can have control.' The excellent improvements made to Java in the upcoming 1.5 release help re-level the playing field with C#. But, it seems like if Sun really wants Java to rule the world, they should heed ESR's advice. Hey Mr. McNealy, listen to this guy... set Java free!"
You don't seem to understand Open Source. This *will* save Sun from bankruptcy. By making Java Open Source, Sun will gain a huge number of developers who will work on it for free. Development staff (namely, programming talent) is hugely expensive and most of them can be laid off save a few who can coordinate and integrate volunteer submissions. As a result, they can cut back on the most expensive part of maintaining Java (the labor!) and dramatically increase their profit margins.
Sun announced several years ago that they would be standardizing on Gnome for their enterprise desktops. They have made significant contributions since then (let's not be fooled: none of these recent public sector / governmental success stories would have been possible without Sun's accessibility work). When they decided to go with Gnome, they already had a production JVM for Linux that equalled the Windows and Solaris (in that order) virtual machines in performance and stability.
When they went with Gnome, Microsoft had long been banging the .NET / C# drum and Miguel had allocated his devoted team of Mono hackers at Ximian with the explicit intent of bringing a modern programming language, C#, to Linux and integrate it tightly with Gnome.
And Sun does nothing! This is an impossible equation to me:
1] Because it invades Sun's most priced asset: the Java and J2EE mindshare.
2] Maybe not technically, at least not yet, but well in developer mindshare.
I don't understand how Sun can let this happen. That's where Java should be! Everything is prepared: all underlying frameworks are in place (industrial-strength JVM on Linux, the new GTK Swing LF, some native Gnome/GTK-Java integration already works, JVM sharing in the pipeline), it's a great way to bring Java to the desktop masses (without having to go through a hostile monopoly) and if Sun doesn't do it, very soon every one will be using their shiny "Java Desktop Systems" to build GTK# applications in .NET on top of Mono.
So I say to Sun:
- Let Java free! You will never get full community and Gnome acceptance until you do.
- Allocate tons of resources to integrating Java with Gnome! And we want real bindings, a buggy Swing Look and Feel is not enough! When a developer sits down to build a Gnome app, they should want to use Java because it's so easy and powerful and well integrated.
- Let people use gcj, GCC's Java-to-native compiler, to produce native binaries from their Java Gnome apps, they're already building for one desktop so screw Write-Once-Run-Anywhere!
- Make your client JVM so good that there's no need to. You're almost there already, most Java apps are today equal to or faster than their C/C++ counterparts on the server side. If Swing hadn't been such a hog and you could tweak that JVM startup time some more, no one would notice the difference on the client-side either.
This may slow down Microsoft's emerging dominance on the free desktop and make that "Java Desktop" brand of yours more than just a PR move.-EE
It's really quite amazing how many of the good coders I know don't use an IDE -- they use an editor and compiler -- maybe vim or emacs and gcc or Visual Studio or something to compile.
.NET for different modules. GNU Make's syntax doesn't change *nearly* as often as Microsoft's project file syntax (and I'm suspicious that they do so to force upgrades). Versions are not backwards compatible, so once you transition to a newer version, you're stuck.
.NET 2002 has more bugs that I can count (note: .NET 2003 seems to be better).
.dsw files into a CVS repository? They look like text, they sound like text (and CVS autodetects them as text), but VS 6 barfs all over itself if it doesn't have CRLF line endings. Try adding someone working on a LF ending cygwin system or a Unix box or a Mac into your development mix, and all of a sudden, you realize that all those deltas in your repository have to be thrown out. Yuck.
.vcproj files, file extensions changing from version to version...argh.
I think a major reason many Windows developers are such Visual Studio fans is that Visual Studio's CLI tools are a pain in the ass to use. The MS virtual terminal really sucks, as does the shell. MS basically killed off all the non-MS compilers back in the day. MS's compilers are the only ones left in wide use on Windows. Since it's a pain in the ass to use the CLI tools, and Microsoft gives you an editor with their GUI front end...programmers end up liking Visual Studio.
I do know one Windows developer that likes the (expensive) Visual Slickedit, though I'm not sure whether it's a full IDE or just an editor. It isn't a compiler, that's for sure.
I've always been rather appalled by Microsoft's IDEs. (The only other IDE I've used is Metroworks on the Mac, and while I didn't strongly prefer either IDE, I really like non-IDE work much more.) Among other things:
* Managing multiple build configurations in VS is a PITA. You can have options that apply globally, or options that apply to individual configurations, but not options that apply to sets of configurations. You can't add and remove object files to a project based on build configuration.
* Incompatibility across versions. Try using VS 6 and a few versions of VS
* Bugginess. VS
* Stupid file formats. Ever tried checking VS 6's
* A pain to set build options. Metrowerks' IDE's build prefs GUI was *much* more logically laid out. You should be able to find basic build options in a GUI within a week of using it. A month after I started using VS, I was *still* wasting huge amounts of time finding various build options in VS. That's silly.
* Can't generate nice graphical call graphs, a la ncc/codeviz.
* Relatively slow -- this is the make system, not the compiler itself. GNU Make is much faster than Microsoft's make system.
* Creates a *ton* of files in projects created. I'd expect a project file, full stop. They have project files, workspace files, cache files,
* The compiler has stopped supporting the current C language.
The only really nice things that I can think of about Microsoft's dev tools are:
* The editor supports very good function completion -- a lot of people cite this as a killer feature. Emacs has etags and fume-mode related functionality. Both are more of a pain to use, and less featureful in some ways (like not showing types of a function being completed). On the other hand, I have had nastiness where the editor got confused about where a constant was defined, and I spent ages tracking down a bizarre bug with two identically-named constants in two projects.
* The debugger/compiler support source-level modification of running programs when one is debugging. God only knows what awful hacks were done to get this working, but apparently it works well enough for general use.
Really, a lot of the people that I know have used Borland's ancient IDE (I ha
May we never see th