Sun to Fully Open Source Java
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 Sun for waiting so long to open source it. Had it been FOSS back when my company was trying to decide what language to standardize on, we might have picked it instead of Python. Thanks!
Dewey, what part of this looks like authorities should be involved?
I would pose the following question to slashdot: how has Java being closed source affected you personally, and what effects do you see this having in the future?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Don't click!
So this is to make up for MySQL? They giveth they taketh away.
jdb2
You could argue that if Java goes GPL, gcj has been successful even if it suddenly becomes irrelevant. The same would be true of GNU Gnash if Adobe were to GPL the Flash plugin. It wouldn't invalidate the open source efforts: far from it, it would accomplish the original goal of having a free implementation of the application.
again?
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Yeah. Just look at what's happened to C, perl and javascript. Oh wait, nothing.
that's simply another clear intention of IT giants to exploit open source community! they opensource it only because they are realizing java is dieing! Look at this: http://www.news.com/IT-giants-accused-of-exploiting-open-source/2100-7344_3-5726714.html
While open source is good, the real issue is the license. The only mention in the article is some parts were not compatible with GPL(I assume v2). What will the license be for OpenJDK? Looking here (http://freejdk.org/faqs/openjdk_license.html) and here (http://www.gnu.org/software/classpath/license.html) it looks interesting...
Does this mean the Classpath exceptions will be removed? Not clear. Kind of a problem for some if it is removed.
FTA: "Once Java is 100 percent open source, it can be shipped as part of Linux, Sands said. Ubuntu has distributed Java as separately available commercial software, he noted. But once Java is fully open source, it can be offered as part of the free Ubuntu distribution and other Linux variants, Sands said."
For me, and I assume most people interested in open development platforms - the real question about using Java will be around the license (once it is open source) and what that means in terms of success, options, and longevity for the projects we build.
No good, you wouldn't be able to see it when doing a nightly build.
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.
Stick Men
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.
Let's look:
C: GCC is one of the worst offenders for non-standard extensions, but very few compilers are 100% compatible.
Javascript: 4 main implementations (IE, spidermonkey, webkit/kjs, and opera), plenty of small differences in the core language, lots of differences in the DOM/Event support.
PERL: only 1 implementation, never will be standardized, requires a perl parser just to parse the syntax.
Do you even lift?
These aren't the 'roids you're looking for.
Great! Does that mean we might see a 64-bit plug sooner rather than later? We've been waiting over 5 years!
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?
If it's so secret, then how come I've never heard of it?
I know java is more than just a browser plugin, but maybe now finally I can run Java with my 64-bit browser.
The fact that mine may be modded "Redundant" makes me a little sad inside.
How many times have I read that Sun is open sourcing java already? So has it happend? May be we should bet on how many more PR they can generate with the word 'Java' and 'Open Source' together....
It is good news for users of java on linux.
Major distros will ship proper java by default (some already are shipping java builds based on the code sun has released so far with bits from elsewhere to try and plug the gaps) and they will be able to patch it themselves to backport security fixes or fix issues with new versions of libraries (there was a bad one involving sun java 6 and a new version of some library recently, I don't remember the details but I do remember sun took ages to get a fix out).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The language for a specific Java version might be consistent but the libraries won't be. Between 1.3, 1.4, and 1.5 there were/are huge changes in the language and libraries, some which broke some of our applications because they went ahead and deprecated some functionality.
I agree that C and Javascript are also a huge pain to work with between versions but you can't say the same about perl. Perl has maintained an incredible job at being backwards compatible with some pretty ugly code. We've been able to take perl code that was written 6 to 8 years ago under perl 5.5 and dump it on perl 5.8.7 without any changes. Some perl libraries you can get from cpan are only compatible with a certain newer version of perl (usually 5.6) but that's because they probably utilize/need newer features in perl. The same is true for Java where 1.4.2 has things that 1.3 didn't have and 1.5 has things that 1.4 didn't have.
You also mention ActiveState perl which kinda went in their own direction as far as packages and other things. But if you want perl for windows that is closer to perl for nix then you might want to try Strawberry perl. Strawberry perl includes a Mingw C/C++ compiler and a "make" tool so you can use cpan.
call me an old-timer, but I remember a time when the linux kernel attempted to support java - http://www.linuxhq.com/kernel/v1.3/100/fs/binfmt_java.c
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.
That's not exactly the story I've gotten from these guys. Directly from ARM 2 years ago in regard to my many inquires about getting specs for jazelle to build a VM for my nokia 770:
"Enabling Jazelle is something that is done by the Java VM and OS, and ARM have worked with many handset vendors and Java platform vendors to ensure this happens as widely as possible, investing many 10s of man years into the Jazelle software enabling technology. If your device does not already enable Jazelle, I suggest you talk to the vendor about this. Please note, the license between ARM and Sun for Java technology is based on the Sun commercial license and not on a GPL license."
It's greed plain and simple. I wasn't asking them for a Sun JVM, just hardware specs to apply to a small free JVM. It's not good enough that you buy the hardware and want to use what you own. You have to pay them again to actually utilize all the features of the chip.
ARM can go to hell.
"If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
I hope this begins the end of the GCJ effort. I'm sick and tired of landing on machines, and finding out only when things begin to go horribly wrong that GCJ is installed, not the Sun JDK. GCJ will have no reason to continue, and should be shelved as soon as the Sun JDK is officially open source.
You mean because Java is the language in which enterprise applications, cellphone games and HD Blu-ray discs are programmed then its success should be put on display?
"I think this line is mostly filler"
- Flash plugin
- Java plugin
- WMV HD movie audio (wma9dmo)
Those are the only few I can come up with at the moment... Lets hope (2) gets fixed soon!Random BedHead Ed wrote
You could argue that if Java goes GPL, gcj has been successful even if it suddenly becomes irrelevant.Even better, the two compilers can be compared, the better ideas identified and the final compilers can get better. Think of the Multics Emacs in lisp and RMC's evenual rewrite of the TECO emacs in lisp.
--dave
davecb@spamcop.net