Beyond An Open Source Java

Karma Sucks writes "LinuxToday is featuring a intriguing article on why Sun should open source Java, as a stronger followup to the recent ESR saga that was reported here. The writer notes: 'Sun needs to do some radical things to improve its chances of survival, and all of them involve Open Source in some form or the other.' One thing the article fails to mention is the threat of Mono, which should be of special interest to Sun, with its vested interest in GNOME."

Comments

as ESR said in CatB

[stonebeat.org]

Give Away the Recipe, Open a Restaurant

High cost of J2EE?

[jhouserizer]

This article mentions outlandish prices (it says $100,000 per cpu) for J2EE (Weblogic and WebSphere).

It fails to note that these are the *most expensive* full-suites of these products that have lot of non-J2EE frills (you can get into Weblogic's base J2EE support for $10k). Other commercial J2EE application servers are well under the $10k mark (e.g. $1500 for Orion Server)

This article also fails to note that there are more than a couple very robust OpenSource implementations of J2EE application servers, that are of course free.

It's obvious that if they pointed these facts out that their argument would be weaker...

Re:Dumb question

[Amsterdam Vallon]

The problem is the way Java is being developed and maintained as a proprietary programming language base.

There are two major Java implementations currently in use -- one by IBM, one by Sun Microsystems. Both of them may come without charge, but are without the freedom that would make them qualify as Free Software.

Therefore, all software written in Java (even software under a Free Software license) running on such a platform will "put the user's freedom at risk" (a quote from FSF/GNU people). It's like running Free Software on Windows.

If you want more detailed 411 about the status of Free Software versions of Java, hit up the following URL:
http://www.gnu.org/directory/devel/prog/java/

Re:Java, who needs it?

[jhouserizer]

You do realize that this is impossible, right?

No, this is not impossible. Read up on just-in-time (JIT) compliers and you'll see why. In a nutshell, the Java Virtual Machine profiles the code that is being executed, then uses sophisticated algorythms to anylize this information, then compile (while the system is running) native code from the java byte code, that is optimized for the environment, and more importantly for the ways in which the code is being invoked. Subsequent calls are executed by this newly compiled native code.

Thus the JIT compiler is able to (often) do a better job at creating optimized native code than a C++ compiler can do, because the C++ compiler doesn't have run-time analysis to use in its decisions of how to optimize the code. The JVM can continuously re-optimize the same code over and over during the life of the application. JVMs of today (and the last few years) do this as standard practice.

Re:Java, who needs it?

[AKAImBatman]

Please explain how this would be faster than writing the app in native code using an assembler and then I'll believe you.

Ok. My assembly is a little rusty, so bear with me. Let's say we have equivalent Java and C programs. They both have to run on a 386 or higher. (Bear with me. I haven't kept up with the MMX/SSE/SSE2 instructions, so I'll have to fake this a little.) Now, your C compiler will see that you want to store a 32 bit value, but has to generate code for a 386. So, it generates the code:

pop AX
STOSW 0x0005
pop AX
STOSW 0x0005

Even though the code may be running on a Pentium Pro (which is optmized for 32 bit code), it's still going to execute those 4 statements.

Now, the Java Hotspot compiler will start and notice the fact that you're running on a Pentium Pro. So when it converts the bytecode to machine code, it creates the following instructions:

pop EAX
STOD 0x0005

That's twice as fast as the C code!

Real code would tend to be running on modern processors, so this example is a little contrived. However, the JVM can (and will) use SSE instructions to do multiple calculations in one instruction, while the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.

Hotspot is also capable of analyzing the running code and regenerating even better assembly that would perform poorly in other circumstances. For example, let's say Hotspot notices that the bounds can't be exceeded on an array. Well, Hotspot will then recompile to remove the bounds checking.

Does that explain it better?

Re:Dumb question

[Mysteray]

It's not really closed source. They let you download the source, they let you compile the source, they let you run the binaries, I think the limitation is on the redistribution of those binaries, and the source. So I would have considered it open source, but non-free.

You can consider it whatever you want. However, there is an official Open Source Definition that most people mean when using the term. Also see the Debian Free Software Guidelines (DFSG). Sun's Java process, though fairly open for a commercial software product, doesn't comply with the letter or the spirit of either of these.

Re:That would suck for java...

[Lobachevsky]

Sun's jvm for jdk1.5 caches JIT code in shared storage.. their 1.5 site even mentions that startup time is almost negligible now, even for large java apps.

I was rather surprised, actually, to see the amount of change from 1.4 to 1.5, at all levels: language, jdk, and jvm. The language itself has a lot of C++/C# features now like covariance and contravariance. 1.5 has more improvement over 1.4 than 1.4 over 1.1, in all aspects, imho.