Java to be Open Sourced in October

thePowerOfGrayskull writes "Sun is now stating that the Hotspot JVM and javac will be open-sourced in October of this year, with the rest to follow by the end of 2007. There is still no word as to which license it will be released under. For those who haven't seen it yet, Sun has previously opened a public developer community site for soliciting feedback and providing updates about the process."

Re:Big deal for OSS

[Anonymous Coward]

"Hopefully" it will be open sourced enough to placate the OSS zealots, yet not so open sourced that Joe Six-Pack-o-Jolt can release his own Java interpreter that fuzzes the meaning of the source code, presenting interesting and unintended execution problems. Repeat that for every distro of Linux and Java will be dead.

Closed Java is worse then closed C#

[Anonymous Coward]

So explain to me how the C#/Mono project is better for open source purists?

C# is Microsoft's solution to the Java problem and most definately will never be open sourced. There are also potential patent issues (I can't believe that there would be _no_ patents that cover C#.)

So because people hate Java (not open sourced), they're embracing an open source implementation of a different closed source project. That makes sense how?

On wait, this is the open source community and what it does doesn't necessarily make sense, there are just emotional responses because someone does something a little bit differently.

Good

[Espectr0]

They better do it fast. Sadly for Java, .NET took almost everything good about Java and fixed lots of its quirks and gotchas. And with Mono, OSS people are giving it a chance too. With dynamic language support being heavily invested in both platforms, having outside contributors is critical.

Now that Java can be redistributed legally (tell that to the slackware guy, he has always included it by default), and will be open sourced soon, it can fight back.

This is what I don't understand about Sun...

[Anonymous Coward]

If they had done this right 5 years ago, .NET would have been stillborn and Sun would be the worlds leading application platform vendor. That's a desirable and advantageous position for a hardware vendor to be in. Instead we're 2 months before a release and we still don't have enough details to consider java for future projects. With the benefit of hindsight, the best business decision Sun could have made back in 2001 would have been to relicense the java source code like they were being asked to.

Better and smaller class libraries

[kherr]

It's definitely the class libraries that make Java "java". The language is straightforward and there are decent JVM workalikes, but developers write their code around the class libraries. The problem I've always found with Java is the bloat of the class libraries, so I'd like to see open source distributions make lean and mean Java variants.

A perfect Java distro would maybe drop all the deprecated methods (will Sun ever do that? Java 1.6 is a good opportunity...) and unbundle some of the least-used stuff like the CORBA and RMI stuff. Heck, even Swing and AWT should be optional packages. Why couldn't Java be structured sort of like a Java Web Start install, pulling in libraries only if needed. Almost everything is connected to the internet these days and good caching of libraries from trusted sources would be a decent way to get full functionality with a smaller initial footprint.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Good

[jalefkowit]

Do you have any data that shows that Mono deployment in the enterprise is increasing, relative to java deployment?

Well, it's not particularly scientific and it speaks more to .NET in general than to Mono specifically, but if you believe Tim O'Reilly's book sales data [oreilly.com] C#/.NET passed Java in popularity/interest over the last year, and is still growing strong (C# sales up 68%, general .NET book sales up 125%; Java book sales are down 6% over the same period).

Of course one could always argue that more .NET books sell because .NET is harder to learn... but having dipped my toe in the Java waters a few times, I find that hard to believe :-)

Re:Big deal for OSS

[_Swank]

but the source or the java libraries IS available. i've been able to look at the source for the standard libraries for years (it's available with the Sun SDK). so am i missing something or are you complaining about the license the source is available under? if it's the second, why? why would java need to be under a more GPL like license? what are the real benefits?

Re:eh?

[FST777]

In the long run, this will make Java more portable too. It took the FreeBSD Foundation some serious time lobbying before they could distribute Java as a package. Even from ports (source, for the non-BSDies here), Java is a pain on FreeBSD, because the lack of support, crazy patchwork and the need to download everything by hand, whilst signing agreements.

I really hope that we can look forward to a working, recent Java version on FreeBSD without the old bugs and the trouble with OSS-principles in the near future. Kaffe / Classpath just isn't doing the trick. I wonder what this will do to OpenOffice.org.

It all depends on the license. I do hope this will draw some of the fine folks at Kaffe / GNU / Apache who have done a great job by recoding Java to Java itself. But then, if it isn't the GPLv3, RMS will probably keep screaming for a "real free" reversed engineered version of Java.

Well then, off to Flash... Adobe?

Re:who cares?

[0xABADC0DA]

What is this "native executable" you speak of? To quote morpheus, "Do you think those are instructions you are running?" Pretty much every so-called native program you run is passed through the ld.so interpreter that relocates the binary and loads shared libraries. Grep the kernel sources for "ld.so".

The only reason you have to ship a JVM with your app is because a) Microsoft intentionally sabotages compatibility (by strong-arming Dell, etc not to ship Java) and b) because Linux distros can't legally ship it because of license restrictions. Java apps work fine on a Mac without shipping their own JVM.

With a JVM installed as a standard system component you run your Java programs just like any other program. You just double-click or ./ it.

Mono has convenient language syntax with C#, but that's it. The CLR bytecode cannot be interpreted well, so hotspot like optimizations are far harder to do. It's a VM trying to be everything to everybody, so it's not really great at anything. It's startup time is far slower than a gcj'd Java program and it's throughput is much less than a hotspot'd one. The only real benefit is that it is oss.

Re:Big deal for OSS

[molarmass192]

You can LOOK at the source all you want, but why don't you make a change, say renaming the util package to utility, post your source code, and send Sun an email with a link to your modified source code. You'll be asked to remove your modified code lickity split. The SCSL is open source but NOT redistributable. So why a less restrictive license? Say I have a KDE based distro, I want to package Java with that distro, but there's a bug in java that breaks the clipboard under KDE but not GTK (this is a real life bug) and Sun refuses to address it because they only support GTK. Under the SCSL, you're toast. Under something less restrictive, you can patch the affected class, and distribute your "fixed" rt.jar.

Re:Open source changes...

[RetroGeek]

result = x.add(y.multiply(BigInteger.valueOf(7))).pow(3).ab s().setBit(27);

My goodness, what a perfect example of why NOT to use operator overloading.

What would you use for an operator? The +, *, /, or what?

How would operator overloading make the code more readable?

And you could always wrap the whole thing inside one of x's methods, and give it a reasonable name.

And ARM Jazelle bytecode specs ... ?

[Big Jojo]

There are a lot of embedded CPUs that have "Java Acceleration" built in. I'm specifically concerned with ARM's Jazelle -- as found in ARM926ejs CPUs like the one in the Nokia 770, for example, and all ARM v6 CPUs -- but there is also Atmel's new AVR32 (Linux port is in the MM tree) and there are a few other processors that do the same thing.

But you can't get specs on how to use that stuff ... and if you ask the chip vendors, the answer is that it's Sun's fault. To get specs, you must sign agreements with Sun. That's for basic stuff like how to preserve the relevant processor context, and how to enter or exit the "execute Java bytecodes" CPU mode, and of course exactly what bytecodes exist. (They just accelerate the bytecodes ... some things need to punt to runtime code.)

What that means is that for example GCC can't use that CPU acceleration by having its Java runtime (GCJ/GIJ) build on it ... one assumes that this means a performance penalty for at least the bytecode interpretation parts of almost every Java runtime environment, though of course it would be interesting seeing how things like HotSpot affect the performance numbers. (The CPUs that have Java bytecode acceleration are by the way not ones that normally have big CPU caches, high clock rates, or very much memory to waste on the stuff HotSpot does.)

So my question: Is this "Open Sourced Java" going to cover ARM's Jazelle? And the AVR32 Java acceleration? And other chips?

Or is it going to be the same-old, same-old? Folk working with embedded systems want to know... the big system bloatware that that Sun ships is not especially useful. Finally loosening the reins on the bytecode acceleration hardware would be a much more useful step.