Sun To Choose GPL For Open-Sourcing Java 407
An anonymous reader writes, "Sun is about to announce its plans for open-sourcing Java SE and ME, according to CRN — and they're going to use the GPL, not their own CDDL or another less-restrictive license."
GPL2 or 3? (Score:5, Interesting)
Re:Are they trying to limit forks? (Score:3, Interesting)
Amazing you guys say this now. Yesterday someone would have argued java is clean and fast and nothing could beat it. Now that, of course, it's happening, you're all for cleaning it up and admitting it's downsides.
Sort of reminds me of Apple's switch to intel. For years powerpc was the best processor for the mac. The g5 was a super computer. The day they switched? Oh the yohan is going to be so powerful! I can't wait for the dual core!
Re:Yesssssss........ (Score:0, Interesting)
Nope, but they can fork it, break it, have people blame "java" and adopt
Microsoft p0wns you again!
This will be super cool. (Score:4, Interesting)
Better; part of your browser that _cannot_ be integrated into non-GPL browsers. They still have to run it as a plugin.
This has mind-boggling implications in terms of patents that apply only to browser plugins (ahem---Eolas).
I've always wished for a Firefox with Java + Flash integrated (does that even make sense?). I don't feel that plugins give as good of an experience as native browser controls.
GNU (Score:2, Interesting)
Re:Too bad it's too late (Score:4, Interesting)
Re:New License (Score:1, Interesting)
If you're unable to fork the source, then how on earth can you call it "open-source"? That's complete rubbish, and this sort of license is exactly what is not needed.
One of the BIG things about open source is that if the original vendor stops supporting and updating it for whatever reason (gone out of business, lost interest, etc.) someone else can pick it up and continue; i.e. fork it. If the license says you can't and the original vendor doesn't explicitly grant you permission, your "open source" driver/program/codec is suddenly worthless because it is not maintained, and nobody can do anything about it.
You also have other problems, such as security fixes. What if the upstream supplier is slow to release new versions? Everyone distributing it (e.g. Linux distributions) isn't allowed to release a security fix for the problem? How is that better than closed-source software? Arguably it's even worse: the source is available to the black hats to look through to find problems, but the white hats can't distribute fixes unless the "one true source" approves it.
Maybe that realised that forking software -- especially big complex things like Java -- is a lot of work, and unless the original developer is doing a REALLY shit job, nobody is going to bother. And they might have also decided they would do an okay enough job that nobody would want to fork it.
A fork would only be damaging if Sun stopped maintaining it, or did really bone-headed things the rest of the Java community hated; otherwise, there'd be some little niche version of Java hardly anyone has heard of, and who would develop for that?
Did you actually read the article? (Score:2, Interesting)
Re:Too bad it's too late (Score:3, Interesting)
Re:GPL'ing Java will kill it (Score:3, Interesting)
For those of you not familiar with it, Java goes hunting for all code at runtime based on the fully qualified (package + class) class name, and resolves methods and fields based on name as well... the code that gets executed at runtime can be completely different than the code compiled against, so long as the method signatures match. That's the crappy, its 11pm and I'm watching the daily show version.
So if I distribute my non-GPL binaries, and GPL'd libraries seperately, am I in violation? What if I use Java WebStart and the user's client downloads the GPL'd libraries from their distribution site? And if I just distribute my binaries and make the user hunt out the GPL'd libraries on their own?
I'm honestly curious.
--
Phil
Re:Yesssssss........ (Score:3, Interesting)
tiny tim's tests for tiny vm's (Score:1, Interesting)
So, if Sun keeps the test suite under a non-open-source license, this would at best mean some patches for annoying bugs. Only if the test suite goes, too, could we get real alternatives.
But these could be huge in the the mobile space, where mobile Linux + mobile Java could be rapidly developed for lots of devices. not LAMP but LAVA. Yum!
Re:w00t! (Score:5, Interesting)
Compat with Apache license (Score:1, Interesting)
Re:Too bad it's too late (Score:1, Interesting)
http://www.thinkfree.com/ [thinkfree.com]
For popularity, I would also add Limewire which is top 10 on every download site.
I'd ask again myself too: Give me a single application which runs on OS X. If I was a developer I would really stay away from MS-Os only languages. As a person in Media, I stay away from MS Only codecs too. I go with whatever MPEG has, including H264/3ivx/AAC
Re:Will this lead to better desktop Java? (Score:1, Interesting)
The J2SE standard library file, "rt.jar", is 38.2 MB in J2SE 1.6.0-beta2. Needless to say it gets loaded "on demand" but still, that's a massive library. And that library doesn't include any of the native implementations (eg, the AWT backend, the I/O backend).
So, keep in mind: doomg absolutely nothing with the JVM requires 5MB. (And I mean nothing, that doesn't even include loading any Java code.) When you start adding in library requirements, the smallest useful Java app I've seen clocks in at about 32MB just to start, and then slowly gains memory past that.
The other fun thing about J2SE is that once it's allocated memory for its heap, it'll never return it, even if the JVM no longer needs it. (So you can have situations were the VM is using 5MB for Java objects, but has 128MB allocated. It'll never return anything past that 5MB. And, being a GCed language, there's no reason why it can't compact the memory space.)
J2ME, on the other hand, strips away a lot of the library bloat and focuses just on a core subset of useful libraries. J2ME focuses on keeping code size down and removing unnecessary bloat. As much of the implementation as possible is done using optimized native code instead of Java code, to keep the size of the environment down.
J2ME is optimized for small memory footprint, at the expense of speed. J2SE is optimized for speed (laughable, I know, but true) at the expense of memory.
Re:Forking is an essential right (Score:3, Interesting)
Inkscape (nee Sodipodi) is another one.