Sun to Fully Open Source Java 374
Dionysius, God of Wine and Leaf brings news that Sun Microsystems will be removing the last restrictions on Java to make it completely open source. Sun wants Java to be easily available for use in Linux distributions. We've discussed the steps Sun has taken to open-source Java over the past couple years. From Yahoo! News:
"'We've been engaging with the open-source community for Java to finish off the OpenJDK project, and the specific thing that we've been working on with them is clearing the last bits that we didn't have the rights,' to distribute, Sands said. 'Over the past year, we have pretty much removed most of those encumbrances.' Work still needs to be done to offer the Java sound engine and SNMP code via open source; that effort is expected to be completed this year. Developers, though, may be able to proceed without a component like the sound engine, Sands said.
Kudos to them, I guess (Score:5, Interesting)
Re:Kudos to them, I guess (Score:5, Interesting)
I suspect I'm with the majority of
Re:Better late than early (Score:4, Interesting)
What fate awaits GNU Classpath? (Score:5, Interesting)
jdb2
Denix (Score:2, Interesting)
Re:What will happen to GNU Java? (Score:1, Interesting)
Re:Better late than early (Score:5, Interesting)
Re:Kudos to them, I guess (Score:4, Interesting)
I installed ejabberd, an Erlang-based Jabber server on FreeBSD this week from ports. For some reason it needed a JDK to install. Normal ports installation didn't work because FreeBSD doesn't have a distribution license. I had to download the file manually, put it in the right directory, then go back to the Sun website, register an account there, log in, download a timezone update, and put that in the right directory too. Only at that point could I install it. And I didn't even want Java in the first place!
The whole process was pointless (it's not like my manual downloading gained Sun anything worthwhile) and felt like a throwback to downloading Slackware floppy disk images back in the early 90s. Every other piece of software I've installed through ports has been downloaded and installed automatically, like it should. But because of this idiotic imaginary property idea, I've got to mess around trying to make the computer happy instead of it doing work for me. This is 2008, I shouldn't have to jump through hoops for bullshit reasons.
Re:Better late than early (Score:4, Interesting)
You say that as though there's a difference. We were migrating from a legacy codebase in Visual FoxPro, and learned well the lessons against using sole-provider solutions. The absolute last thing we were willing to do was throw ourselves again to the mercy of someone else's whims. With Python, and now Java, we get to keep some of that control.
Re:Java vs. Python? (Score:2, Interesting)
What are the pros and cons of each when you have to interface with another language or platform?
How do you deal with code written in C++ and PERL, for example? And, for a couple of years, Ruby has been a buzzword.
Re:What will happen to GNU Java? (Score:3, Interesting)
I still want to know when the ARM hardware support for Java will have public specs: Jazelle, as found on ARMv5TEJ and ARM6 cores. The ARM926ej-s cores (ARMv5tej) are some of the most widely used ones. ARM6 is found in Nokia N800 series. Until Jazelle specs become available, none of those chips can leverage the hardware support for Java using a GPL'd JVM. They have to buy a JVM from somewhere else. This affects the JVM used with Android, for one example. It increases the runtime footprint of JVMs on embedded hardware ... to the degree that using Java isn't necessarily practical.
And what does this have to do with Sun, you ask? When I ask ARM why they don't make the Jazelle specs public, they say it's because Sun required them to be closed, so that can't change until Sun OKs it.
Of course, I've kind of lost interest in Java, myself; I don't work in areas it matters any more. If Sun hadn't been mismanaging it, I might not have moved away from such areas. Oh well; that's just more water under the bridge.
Re:Better late than early (Score:5, Interesting)
The big problem has been Sun's corporate mindset. Until recently, key decision makers at Sun, both on the business side and the R&D site, seriously believed that they were smarter than everybody else, and had no need to listen to anybody else's ideas. That's why Sun stuck with SPARC processors so very long after it became obvious that commodity processors were the future — SPARC architecture is superior to x86, end of discussion. It's also why Sun's first attempt to move to commodity systems (by spending $2 billion for Cobalt Networks) was a total disaster: the Cobalt people couldn't get any respect from the rest of Sun, and quickly moved on. I can think of many other examples.
I was a contractor at Sun/JavaSoft in '98, and saw this attitude all over the place. In some cases, I couldn't get access to the FrameMaker source for key specifications because the spec owners feared "forked" copies of the specs!
The really sad thing is that many of these people were every bit as smart as they themselves thought they were. But their raw intelligence was often wasted, because you need a certain willingness to collaborate to create a real product.
I recently came back to Sun as a regular employee. I like to think this intellectual arrogance is no longer a major problem here. Part of this is the example set by current upper management, which seems to understand the problems I describe. But the big reason: most of the my-way-or-the-highway geniuses have been hired away by Google.
Re:Kudos to them, I guess (Score:3, Interesting)
And because Java itself wasn't in any of the distro repositories, no program that depended on java would be in the repositories either. So any java program I wanted to run was going to be annoying to install, so I would often try and find an alternative in a more usefully supported language that could be managed by my package manager.
The Java browser plugin, requiring java was also a pain to install, so I never bothered with sites that required a java plugin -- it was too much hassle.
So all in all, I rarely, if ever, had any java software on my machine, and I suspect this is true of a lot of people. I suspect this had a chilling effect on Java under Linux/*BSD's, or on websites as plugins since people would tend to use/support/develop on software that was more easily installable.
Re:What will happen to GNU Java? (Score:2, Interesting)
Well, gcj produces native machine code, so it's scope is obviously a bit different. The resulting binaries are not very much faster than Java Bytecode, but at least they require a lot less memory.
Also, who ever said the FOSS community can't have two or more different solutions to the same problem?
Browser Plugin (Score:5, Interesting)
Re:Better late than early (Score:5, Interesting)
Re:Better late than early (Score:4, Interesting)
That is exactly how we feel about it. FoxPro certainly isn't my choice of development environments, but our old code runs - and runs well. The only reason we're migrating away is that it's officially a dead language, and it's crazy to keep developing on something whose owner has said has no future.
So that's how we ended up on Python. Java probably would have done most of the same stuff, and it'd probably be easier to find Java programmers where I live, but we weren't going to fall sucker to that problem again.
Re:I'll believe it when ManBearPig flies. (Score:3, Interesting)
Re:Better late than early (Score:3, Interesting)
For the record OO, also has a clause that stops it being fully GPL, thats why neo office code cant be used
One part of this I don't understand and the other part isn't factual. If OO wasn't "fully GPL" then NeoOffice wouldn't exist in the first place. It is true that Sun only accepts contributions if the copyright is turned over to them but that in no way un-GPL's the software.
As for NeoOffice, they contribute or at least attempt to contribute bugfixes under Sun's terms because bugs in the core OO code affect them too. But there is a political/personality problem that cause the OO devs to ignore the NeoOffice guys. For instance, the X11 OO on OS X was unable to open files on a network share. The NeoOffice guys had this problem fixed for two years before it was fixed in OO and had to keep forward porting the fix because NeoOffice is Politically Incorrect over in OO land.
Re:Will this mean a 64-bit plugin sooner? (Score:4, Interesting)
IcedTea works pretty well on my X64 Debian system: http://en.wikipedia.org/wiki/IcedTea [wikipedia.org]
I still have a Sun 1.6 JDK installed, which I use for all my development work; however, IcedTea is my default JRE, and I've not had any issues so far. It's eased my need for a Java plugin. no more 32bit firefox^W Iceweasel for me!
Re:Better late than early (Score:1, Interesting)
It took Java quite some time to get a decent sized library (and still there is no central repository, unless you stick with the Apache projects only).
Btw, I doubt 1500 Java Developers working on 40 projects would be very efficient, that's nearly 40 a project, it would collapse. And if the project was big enough to split up into subprojects, then one Perl developer would be in seriously over their head regardless of their skills.