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.
I think that Sun has a few other 'real' assests still alive and kicking. Among these assets are UltraSparc Servers, Solaris, and Java System Application Server Enterprise. Granted Sun's Application Server doesn't have the presence of a Weblogic or a WebSphere, but with the right investment behind it who knows. As to Sun's UltraSprarc's and the Solaris OS, the numbers I found weren't huge but certainly assest worthy: "Sun had about $50 million in orders for the V210 and V240 servers, Chief Financial Officer Steve McGowan said. The revised systems are in testing and are expected to ship by the end of July or in August, he said." - C|Net
I think you might say that they are more than the "one trick pony" that many people believe they are.
"If you're flammable and have legs, you are never blocking a fire exit." - Mitch Hedberg
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.
I'll think you'll find Sun does release the source code for their JVM and compilier, here.
RegardselFarto
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
You missed a few:
http://www.hp.com/products1/unix/java/
http://h18012.www1.hp.com/java/alpha/
http://www.sgi.com/software/java/
http://www-106.ibm.com/developerworks/java/jdk/ind ex.html
http://www.apple.com/macosx/features/java/
So it looks like we have JVMs for, at least, Linux, Solaris, Windows, OS X, Irix, AIX, HP-UX, Tru64, OpenVMS, OS/2, and z/OS.
What was the list of platforms for C# and .NET again?
Athough you will occasionally see deviations:
Gross profit is your profit after your manufacturing or input costs are covered. If we were talking about a PC OEM this would include components in a cheap computer (RAM, HD, mobo, CPU, case, and assembly as well as depreciation on your factory). This ranges from about 15% (grocery stores and PC manufacturers) to 90% (software developers) an average manufacturing gross margin is about 40-50% in decent times. Traditionally this cost has a high portion of fixed costs (costs that do not change with small increments of production).
The next costs taken out are for selling, marketing, administration, and product development. Some companies pull all of their depriciation costs out and put it here as well. This is where most of the paychecks are accounted for on an income statement. Other than ERP systems and office buildings, or the developer's toys, there aren't a lot of fixed costs here (labor is still considered more of a variable cost)which is true for commissioned sales people, but less true for an R&D staff. After these costs are removed what is left is operating profit. Overall averages are about 10-15% nationally, with retail sales operating margins at the low of 3-5% and software development reaching as high as 50%.
Next groups get quite confusing as different companies pull any combination of the following out interest, taxes, or other costs. Once all three have been removed you are left with net profit. Sometimes a preferred stock dividend (an archaic cross between stocks and bonds certain tax laws have largely rendered these a thing of the past, but they are still occasionally used as convertable instruments) is removed and net to common shareholders is quoted but that is fairly rare.
In response to the grandparents, Microsoft has never reported more than $4 billion in operating profit in a quarter (about 2.5 billion in net profit) so the first poster (60-80 days of profit) is more correct. Usually daily/monthly rates are applied to cash generation, but that is a lesson for a different time.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.