Forgot your password?
typodupeerror

Sun To Choose GPL For Open-Sourcing Java 407

Posted by kdawson
from the open-'er-up dept.
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."
This discussion has been archived. No new comments can be posted.

Sun To Choose GPL For Open-Sourcing Java

Comments Filter:
  • GPL2 or 3? (Score:5, Interesting)

    by EmbeddedJanitor (597831) on Tuesday November 07, 2006 @11:42PM (#16762843)
    Next fight: which version?
  • by fimbulvetr (598306) on Tuesday November 07, 2006 @11:48PM (#16762895)
    Java needs a branch that has the cruft removed, both from the VM and from the class library. A new class library is needed, taking full advantage of generics and the other Java 1.5 features. The VM needs some major upgrades, notably in the area of garbage collection, memory usage reductions, and speed improvements. The backwards compatibility requirements currently forced on Sun seem to have prevented this from happening.

    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)

    by Anonymous Coward on Tuesday November 07, 2006 @11:48PM (#16762901)
    Another thing Microsoft can't own.


    Nope, but they can fork it, break it, have people blame "java" and adopt .Net.

    Microsoft p0wns you again!
  • by WhiteWolf666 (145211) <sherwin@amira n . us> on Wednesday November 08, 2006 @12:34AM (#16763259) Homepage Journal
    Imagine Java not as a plugin, but as part of your browser.

    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)

    by treak007 (985345) on Wednesday November 08, 2006 @01:27AM (#16763645)
    This means that Java would be able to be included in linux distos by default, rather then requiring the user to set them up.
  • by pembo13 (770295) on Wednesday November 08, 2006 @01:38AM (#16763725) Homepage
    Well, just to speak to the otherside - I hate C#, and I think its more than the fact that I typically have to be on a Windows machine to code it. I very much dislike some of the design choices made - my point being that C# is one of those subjective things (IT didn't help that every tiem I go to the C# irc channel I get yelled at)
  • Re:New License (Score:1, Interesting)

    by Anonymous Coward on Wednesday November 08, 2006 @01:40AM (#16763751)
    Submit upstream if you wish, but you can't distribute unofficial builds, or fork the code.

    If such a license existed, it might be considerably more likely to see more open-source codecs, open sourced Flash players, plugins, video drivers, etc.

    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.

    Sun has said forever that the code is basically out there already, and they had no qualm making it open-sourced over than the fork issue, and the only reason for this lengthy delay was coming up with an appropriate license. So why just settle on the GPL?

    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?
  • by americanincanada (887832) on Wednesday November 08, 2006 @01:52AM (#16763801)
    The fifth paragraph reads, "Santa Clara, Calif.-based Sun declined to comment on its open-source Java plans and licensing choice" That doesn't sound like a definitive answer to me. The ONLY thing that is actually said is, "...using a GPL license is very much *on* the table..." (q.v. http://blogs.sun.com/jonathan/entry/busy_week1 [sun.com] ). This does *not* commit sun to *anything*.
  • by compupc1 (138208) on Wednesday November 08, 2006 @02:22AM (#16763971)
    Traditionally Java has been better for web applications, and the Microsoft products for desktop apps. But that's changing, in no small part due to the Rich Client Platform from the Eclipse foundation -- a desktop application framework which puts Java in the arena in a way it never previously was. And on the Microsoft side, .NET (especially the more recent versions) have greatly improved Microsoft customers' position for web-based apps. Really, you'll probably see either environment in smaller shops, or a mixed environment for larger organizations.
  • by ldspartan (14035) on Wednesday November 08, 2006 @03:29AM (#16764353) Homepage
    How do the linking restrictions of the GPL apply to Java bytecode that isn't (by default, without a custom classloader, 99%+ of the time... etc.) traditionally linked as we think of it in C/C++ (and most other languages)?

    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)

    by L7_ (645377) on Wednesday November 08, 2006 @03:35AM (#16764373)
    but then again, you will have all C# code running on a new VM within a year... when Parrot and Java share a GPL'ed VM, developers can write platform agnostic code in Perl, Java or C#; who will need .NET or Mono?
  • by Anonymous Coward on Wednesday November 08, 2006 @05:21AM (#16764837)
    As someone who tested the JDK and negotiated long and hard with Sun over open-source license for J2EE, I submit that the code is worth little without the test suite, and the code would be relatively easy to write with the test suite.

    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)

    by caluml (551744) <slashdot.spamgoeshere@calum@org> on Wednesday November 08, 2006 @05:53AM (#16765023) Homepage
    It's better than wolfbagging. I'd never heard of it, and looked it up on Urban Dictionary - and wished I hadn't.
  • by Anonymous Coward on Wednesday November 08, 2006 @05:57AM (#16765039)
    Sun is already shipping in particular XML stuff licensed under the Apache License 2.0, which the FSF believes is incompatible with the GPL. Considering that Jakarta is such an important pool of code, what are they doing about license compatibility?
  • by Anonymous Coward on Wednesday November 08, 2006 @06:04AM (#16765091)
    I'd also add Thinkfree Office which runs on every platform having a modern java, a full feature desktop office which even runs in browser if you want.

    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 ,ignoring DivX or any avi based format. Lets say, if MS offers Windows Media server free (they do,generally), I ignore it and buy/get Helix (RealNetworks), Quicktime since they are not bound to MS-OS,
  • by Anonymous Coward on Wednesday November 08, 2006 @10:10AM (#16766815)
    It's more like the J2SE VM and library is massively bloated. Running "java -version" requires 5MB of memory. That involves running absolutely no code and no Java application.

    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.
  • by MenTaLguY (5483) on Wednesday November 08, 2006 @12:00PM (#16768905) Homepage

    some prominent projects have only survived due to forks (GCC comes to mind)

    Inkscape (nee Sodipodi) is another one.

In 1869 the waffle iron was invented for people who had wrinkled waffles.

Working...