Skip to main content

In the long run, Apache Harmony will be...

Good for Java
56% (429 votes)
Bad for Java
13% (100 votes)
Not much of a factor either way
31% (236 votes)
Total votes: 765

Comments

it's good for linux distros

For now, the license donnot allow any community distro to include the JDK, it's bad for linux novice and cause some inconvenience. Also I hope there's some innovation in the implementation of harmony.

There may be trouble ahead ...

The only advantage I can see is if the OOS community is less hostile to java. OTOH, a flaky, immature implementation of a JVM would damage the language's reputation.
One thing I really don't want is having to test system properties all over my code to add conditional code for different JVMs.

I have to agree

Its really bad idea.. the best they can hope to achieve is a mirror of the existing sun implementation under a fully open source license. Any other result will mean we will end up with a new flavor of java. Which just adds more of a head ache in the comunity than benifit.

lol

What a monumental waste of time. The open source communists love to sail in the wake of innovation and declare victory by giving away what innovators have paid a high price for.

open source!

The problem is that Java is not open source, and tomorrow Sun may decide to change its licensing or something like that. What's worse, Sun can be sold to, say, Microsoft. What will that do to Java?

open source!

Sun absolutely HAS been changing it's licensing over the years -- for the better! Plus, some say that Java has too much baggage and we should start over, so if it gets bought out or licensed the wrong way into oblivion, we get to learn something new, different, and cool and have plenty of job security. Get over it, open-sourcing Java is a non-issue.

open source!

Actually, I think I'd have to say that this is one of the best arguments I've seen on the topic. It addresses things from multiple angles and is short. But it still leaves out the question of how to migrate existing infrastructure in the case of a sudden change for the worse. I agree that it doesn't seem to be on the horizon, but it's still possible at some point in the future.

open source!

Thanks for the reply! I also think the issue of migration is a non-issue. I don't expect to still be coding Java in 10 years, anyway -- something new and better will take over. It's just the way things work. But from a practical standpoint, as far as I understand licensing changes are not retro-active, so older versions of software can still be used. There's obviously plenty of room to work with the existing JVM structure -- witness Groovy, Jython, AspectJ, etc. etc. IBM, BEA (though on the buyout track), Oracle, and others also have big investment in the existing infrastructure and are not about to abandon it. Short of market collusion between said entities and Sun to change the license for profit, which the market itself is unlikely to stomach, there's very little chance that licensing changes will be made for the worse. It will remain free, and if anything, Sun would be most likely to turn over Java to a foundation or IBM if it no longer wanted to spend the money on it.

In the long run...

- Though a fantastic idea I'm afarid Apache Harmony will always stay behind on the SUN implementation. - Consumers are not really waiting for it I think. Oh and what was the problem with SUN owning Java again? :-)

In the long run...

I agree. Yes, I expect Harmony to always be behind Sun's implementation. And if it ever gets traction, then we're worse off in having to test our Java code against multiple JVMs/JREs on each of the multiple platforms we already have to test against (even with automation this means a TON of extra testing, which wastes my time). And in some cases we end up having to bundle extra stuff (media encoders/decoders for example) regardless of what core JRE the user is running in order to ensure consistent API and performance, which is a huge duplication of code and snub at code reuse. If we have to have an open-source Java JVM/JRE it's only for open source's sake and for no other good reason. That tells me that there's a problem with open-source's licensing, not Java's, if it can't interoperate with ANY kind of software just because a different license is used. Sounds broken to me. There is some room for Sun to work with others in getting Java distributed better, but geez, work though them instead of writing a whole new huge software platform. I just don't see the real benefit to justify the cost, and if anything I see this as a potential UNIX or Linux fragmentation that we just don't need. C'mon guys, If you want to make use of all that spare time you have, write something new and make it better instead of rewriting old stuff that already works just fine.

Spec vs. implementation issue

The funny thing here is that supposedly the Java way is to have open specs with competing implementations. I find that this usually causes pain, especially for extremely large and complicated specs. And there are more than enough of those among the JSRs.

That's one of the reasons for open source. You can enjoy one implementation, and who cares if it follows a spec. Python and Ruby communities (so long as they avoid Jython and the like) get to enjoy this situation. Java (at the core) effectively enjoys this too, even though it's not open source. The thought of having two canonical implementations scares people.

One of the benefits of Mono is that (despite trying to be somewhat compatible with MS.NET) it's standing up as its own name in the Linux crowd. By being its own thing (which psychologically drags in Gtk# and such like), people can think, "I'm coding to Mono." I think that's why it's getting some traction. It's being an implementation with momentum rather than just an implementation of a spec.