Sun doens't need to open source java but it should work out any problems/reasons for the SUN JDK and JRE not to be included in all Linux distributions. This needs to be worked out. As for other decisions it really is up to SUN, they have a good track record so some faith should be put in them for the future.

Out of the blue, with its unstoppable passion for homing in on THE issue of the day, the world's most-read business magazine - BusinessWeek - has triangulated on Java as one of the the software world's key ignition points right now.

Does SUNW carry the value of the Sun Java brand on its balance sheet? if so, what is it in $$ terms?

Two words of advice to Mr Schwartz: CUT SPARC

Perhaps SUN's return to glory would be in merging with Google, making McNealy's dream come true by creating the first true challenge powerhouse against Microsoft that includes a credible Enterprise strategy?

Schwartz quote: "Value in information technology is coming down to how efficiently you can get something done. Whether it's building a 30 teraflop grid or a web services infrastructure; powering a Java handset or an entire datacenter. From what and who I see, the folks who measure that efficiency are getting more technical, not less."

I've never really understood why Sun doesn't just dual-license the Java VM and libraries like it does with OpenOffice. This would allow Linux distributions to include both the JDK and JRE and wouldn't preclude commercial developments. This wouldn't be that different from what Trolltech does with Qt. With Qt, this limits commercial KDE development, but Java already enjoys strong commercial support. If they GPL'd (not LGPL) the JDK, they would open doors to the Open Source community while still supporting their commercial contracts.

I wouldn't think that forks would be a big problem either, as everyone would likely stick to Sun's JDK by default. I certainly haven't run into IBM's JVM very often and one needs to look no further than Mozilla, OpenOffice.org and Qt for evidence that dual-licensing doesn't necessarily lead to uncontrolled forks.

The truly bizarre thing to me is that this hasn't already happened. It's not like Sun is trying to keep Java sources secret. They've already exposed them to the world with their fairly liberal research license.

Sun had better get aggresive if they want to survive! Buying NOVELL would be a start in the right direction!

The right direction is open source...the suggestions listed on this article are very interesting. Don't forget that JS is more software minded than hardware.

Is it true that Digital Equipment Corp. (remember them?) coined "the network is the computer," not SUN.

In 1997 I went to a Java symposium hosted by Sun, Netscape, and Oracle. Scott McNealy gave the keynote and touted the whole "Network is the Computer" thing. Scott envisioned
Networked (semi-dumb) terminals that had a browser in place of a desktop and embedded java to run applications. Oracle and Sun backends would provide data and application hosting, respectively. From a question asked, he explained his idea differed from, say, an XTERM because the application would be hosted entirely on the terminal (and a small disk or SRAM cache) and would disappear after any actions were complete and that memory was needed for other tasks (basically terminals were memory and a network card, no data storage required). These applications would be bought on a per-use scenario - if you needed Word, you'd pay 10 cents and use Word.

The model he envisioned in 1997 never appeared in reality, as far as computer software goes - the idea was to "rent" applications, not buy them (the closest success I can think of is MMORPGs and ATM machines [i.e. realtime bank account checking], but both are quite different in implementation). The over-the-web purchase (non-rental) model he didn't mention, however, has taken off very successfully (e.g. iTunes). He also touted java based smart cards at that conference, another technology that was pretty much stillborn in the US, but is fairly successful overseas.

Neither of these were necessarily bad ideas - in the rental case, everyone is always using the latest update and if you don't like or use an app much, it doesn't kill you financially. In the smart card case, you can do stuff like bring your medical history with you in case of an emergency or require a PIN before making transactions. I also think Scott failed to anticipate computer hardware prices taking a massive nosedive in late 1997 (memory dropped several hundred dollars, disk got cheaper, etc).

As far as AJAX goes, I'm mixed - Scott did propose something like that in his rental model, but it was using Java and Oracle, not Javascript and XML.

I remember hearing about two or three weeks ago that Sun said it was committed to "Open Sourcing all of its software, everything they make."- this is from LugRadio and a Sun representative.

Given this /very/ progressive stance, I don't see why they're stalling when it comes to Java.

If anything, this slows Java adoption.

Java was all the rage in the late 90s. Had they made it Free, I think it would have been a tour de force. Now we see competition from simpler technologies. We're learning that we don't need a J2EE infrastructure when a simple Model-View-Controller model with a database backend will do the job just as well, and so on.

Freeing Java would spread adoption, if nothing else than by including it in every distribution shortly thereafter.

This new license system isn't good enough, it'll just frustrate people.

As a former CS student *and* instructor, take my advice: run away from Java as fast as you can. I'm not saying it's a bad langage/environment or doesn't serve some audiences very well. But Java's like cigarettes, starting on them too early stunts your growth.

CS students need to learn as many different programming approaches and concepts as they can. Procedural languages (C et al), iterative (generators, Python/Ruby), functional (lisp), declarative (prolog), message passing, object oriented, generic programming, closures, static vs dynamic typing, etc. Breadth of exposure to different approaches is crucial to knowing what approach to take with real-world problems. This should be coupled with a depth of understanding of what the system does 'under the covers' at each level. It makes all the difference in the world when facing unexpected problems and differentiates a code monkey from an engineer.

Unfortunately Java covers only a couple of these areas and none of them particularly well. Standardizing classes on Java is one of the worst things a CS dept can do. If you're stuck in this boat, all I can suggest is play around with other languages every chance you get.

Sun's problem is that they don't want something that isn't Java to take the place of Java. I think I have the solution and it works using existing laws.

All Sun have to do is register the Java name as a trademark. There are already established regulations covering the use of trademarks. Sun could licence the trademark subject to any conditions they liked, so all they have to do is impose the condition that the Java name can only be used to refer to software products that pass a suite of tests specified by Sun. The software could then be released under the GPL. The GPL is a copyright licence only, it says nothing about trademarks. Clause 7 makes the distributor responsible for ensuring compliance with other IP considerations.

If someone, i.e. Microsoft, implement an extended but incompatible "Java", they won't be allowed to call it Java. And without the recognised Java brand name, it will be all but worthless.

The server side guys never had a problem with downloading Java. I can only assume that this is a move for the desktop.

The problem (as I see it), is that it's too late for any kind of java desktop resurgence. How come Sun never produced any kind of Java Gnome/Gtk+ apps? They do employee Gnome contributors and Gnome is their desktop. Oh right....Swing is enough for everyone,*rollseyes*. Maybe four years ago if they had gotten behind Java gtk+, and made this move things would be different, but much of the open source desktop developers have moved on to Ruby, Python, and Mono. And there's still a lot of development done in C/C++. Even on the server side, many people are moving to LAMP+Ruby.

So my question is what is Sun's reasoning for doing it now?

Open sourcing Java would at the least allow Linux vendors to distribute and integrate it into their distributions, which would be a great boon. Sun could still make "Sun Java" even under open source, and have every bit as much control over "Sun Java" as they have today.

As a bonus they could accept independant patches (though they wouldn't be forced to). Most people would still want "Sun Java" and not "Billy's Homebrew Java" (which wouldn't even exist anyway; I don't know why everybody seems to think open source leads to forking hell).

So many of the essential Java tools and libraries are already open source (and not forked to hell). Sun is making a mistake by keeping Java proprietary.

Open-sourcing Java would be very nice and useful for the Linux and BSD communities since the World Wide Web still "requires" the Java Plug-in (please notice quotes) and OpenOffice.org does have full functionality only with the Big Official Proprietary JVM installed. Separately from the distro/OS you have and its own powerful packages installation system.

Having it freely available would make Open Source systems a step more powerful and a step less handicapped in the desktop environment.

What Java needs, in decreasing order of importance:

1) A free software license (GPL?) to allow for fast, active development, quick fixes of current problems, and license purity. Plus, imagine the boost if all those talented GCJ people put their efforts into the already rich Sun codebase!

2) Constant references! Please! Java's encapsulation is about as secure as Internet Explorer. A harmless getter method for a private member variable allows you to replace that variable with anything of your choice, because you effectively get a pointer to the member. The only current solution is to copy everything in the getter, which is unacceptably awkward and slow. So much for design by contract.

3) Sane memory requirements. Right now coding an inherently memory-intensive app in Java is very very difficult. I tried it once, and had to rewrite in C++ to get anywhere.

The supposed point of "Java was write once, run everywhere". Without it being open source, it's "write once, run only where Sun feels like it". That's why it doesn't work on Linux x86-64 native, Linux/BSD on non-x86 systems, OpenBSD on any system, etc.

While I agree that open-sourcing Java won't be a magical solution that will somehow improve the codebase and allow people to run all sorts of languages to run on the JVM...there is in my opinion a good reason to get other languages to run on the JVM--to compete with .NET.

Right now, .NET devotees don't have to use C# to get .NET code, they can use a scripting language instead. Having a scripting language (like PHP) that people can run on the same VM as Java would be a great boon to both people who use the scripting language as well as to Java's popularity in general.

All of this is terribly ironic to me. I've worked with Java for about 6 years now. It's considered the Enterprise Open Source solution (because admin types typically confuse open source with "free and runs on lots of platforms) usually. So it's either Java or Microsoft in every shop I've ever worked for. No PHP. No Ruby. And often Java is paired up with Linux, MySQL, etc.

So I find it funny (although I understand the point, but it's still funny) that people consider Java to be so difficult because it's closed source. In every shop where Microsoft is the choice, the decision is usually made because the stack is predictable. It's predictable because Microsoft controls every aspect of it from the database to the app server to the language you use to code on it.

So open sourcing Java would probably have the unintended consequence of giving Java a perception problem in the eyes of manager types. It would become risky on the same level as Linux and MySQL and so instead of being the safe, "adult" part of that crazy open source stack, it would just become one more piece of it. Albeit a powerful one, but it would probably push more people into the arms of Microsoft. Sorry, but that's been my experience, given what I've witnessed in the industry lately.