Slashdot Mirror
Two Takes on the Java Dilemma
Joe Barr writes "NewsForge is running a pair of excellent commentaries on the plight of Java and the Java development community following the recent "settlement" between longtime rivals Sun and Microsoft. One is by Rick Ross, the articulate leader of JavaLobby, entitled "Where is Java in the settlement?" The second is "Free but shackled: The Java trap" by Richard Stallman. Good reading. Both commentators put their finger on the heart of the problem, albeit from different perspectives." Yes, Newsforge and Slashdot are both owned by OSDN.
RMS's point wasn't that Sun is doing something wrong by holding onto Sun. RMS's point was to say to the Free Software community that any software they write that depends on a non-Free platform, library, whatever is not truly Free. Like he said in the article, this is the same as his beef with KDE - but that beef is now gone thanks to TrollTech going to a dual-license scheme.
His point is that Free Software developers who choose to use Java are entraping themselves, not that Sun is trying to maliciously entrap developers.
It's also worth pointing out that at no point in the article was he talking about OSS developers.
No, he does know what he is talking about. If a programmer uses an object from say java.rmi.server on Sun's platform, who is to say whether this feature is implemented in another virutal machine? Are you familiar with how up to date the dozens of other JVM's are with Sun's latest release of java? If no other JVM is implementing this, then it is effectively sun only, regardless of whether it is prefaced by com.sun or not.
Also on sun's JVM it doesn't say com.sun, it is all just "java.whatever", "javax.whatever", etc... when you import a package.
Java the programming language is well-defined and documented and anyone can write their own compiler/interpreter for it, just as they would for Pascal or BASIC or Lisp.
Java the class libraries are, in my opinion, one of the reasons for the success of Java. They are (for the most part) well thought-out and provide a lot of useful functionality (e.g., network, GUI, data structures) for developers that enables focusing on solving problems instead of doing basic stuff over and over. This is exactly the same type of thing that helped C take off in the 1970s with the standard Unix libraries and why CPAN exists for Perl. These libraries could be replaced and/or clean-room implementations created, which is indeed happening.
The Java virtual machine is the component Sun has been controlling, for good reason. The JVM is what provides the cross-platform execution and consistent behavior. It also defines a lot of Java features that go beyond the language specification such as runtime class loading and heap management. These are powerful aspects of Java and to have inconsistent behavior would be nightmarish for developers (and was, early on).
IBM and Apple are two companies that have developed their own JVMs that behave consistently with Sun's but are not written by Sun. IBM even has an open source JVM separate from their licensed one. There are other JVM projects in existence, at different stages of maturity.
I agree completely that too many major companies have too much invested in Java to let Sun just nuke it or hose it over. Java is in a much more stable state than C#/.NET. Microsoft could announce tomorrow ".NET XP" which could be 180 degrees different from what is today, whereas Sun can't arbitrarily change the fundamentals of Java without losing a lot of support from the major players and individual developers who make Java successful.
I don't know about the rest of his article -- seems ok to me -- but his memories about Bill's "investment" in Apple are rather flawed:
1) Apple did not abandon their Java compliance projects. Today, they are arguably among the best Java development and deployment platforms out there.
2) It is hard to say Apple used the $150M to kill the clones. They had already been killed by the time Steve and Bill got together.
My recollection of the event was that the big thing that Apple got was an endorsement from Microsoft, a notion that Apple wasn't going to die in the next few weeks.
I don't know what those other problems you speak of stem from, for I have many RedHat boxes and have not experienced them. Perhaps the admins are idiots?
/usr/local, this goes in /opt, this goes in /usr/share/, that goes in /use/bin, this goes... over there! Oh, and you don't need the Sun 'tar' utility. Use this instead! Ugh.)
Yes and no. The GDM problem, for example, happens when you configure the hostname. For some lame reason, GDM tries to do a reverse lookup on the hostname, and fails to start if it can't. I don't remember all the details right now, but it didn't even like it if you used a hosts file.
The starting of daemons problems are caused by RedHat's insistence on trying to map XinetD to the concept of Windows Services. The configuration tools never work right, and the whole thing happily blows up. I've tried to tell admins to use the command line, but they want to do it the "RedHat approved way" for purposes of support.
It may have improved, but last I checked, RedHat systems are littered with extremely complex shell scripts to do every little thing. These shell scripts work fine if you don't dive too deep into the system, but they easily start breaking as soon as you start trying to ratchet up security, or install system level software.
RPM hell is, well, RPM hell. Eventually you install yourself into a corner, where you've got a set of mismatched dependencies. After that point, you can only force installs. You can't even uninstall anything because the dependencies have gotten so tangled. Thus the "standard" position for managing RedHat servers is to multiply them like windows machines (one task per machine), and reinstall the OS every time you requisition a machine. This procedure is covered over by the constant need to "upgrade" to the latest and greatest (and highly unstable beta software) release of RedHat Linux.
A Solaris box is also difficult to work with on the first go-round. Usually you get sent to Sun classes and everything becomes clear.
A Solaris box is complex. But I've really never seen anyone do irreparable harm through normal use of the machine. I remember when I received my first Solaris machine. I was a Unix newb, and had to struggle through quite a bit. But I found that the machine was well designed and laid out, and eventually I found everything I needed. The only concern I ever had with Solaris was trying to reign in the Open Source software from making a big mess out of my hard disk. (Ok, this goes in
Javascript + Nintendo DSi = DSiCade