Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Sun to Change Java License for Linux 226

daria42 writes "It looks like the days of downloading Java every time you re-install a Linux box may be at an end. Reports are trickling in that Sun plans to alter the Java license to make it easier to bundle the JRE with Linux. From the article: 'Sun has faced calls several times to open-source Java, which advocates say would foster innovative open-source development. The company has resisted formally open-sourcing all of the Java software, but it has dramatically changed the development process around Java and changed licenses to make it easier to see Java source code.'"
This discussion has been archived. No new comments can be posted.

Sun to Change Java License for Linux

Comments Filter:
  • Finally! (Score:4, Funny)

    by pryonic ( 938155 ) on Friday May 05, 2006 @08:46AM (#15269332)
    It's about time they woke up and smelled the coffee!

    I'm sorry...

  • Sweet... (Score:3, Funny)

    by racebit ( 959234 ) on Friday May 05, 2006 @08:48AM (#15269342) Homepage
    Three cheers for sun *reaches for mug java*....o wait, my self heating mug exploded
  • Hard.. (Score:5, Insightful)

    by ZoWnX ( 710685 ) <[moc][tod][xnwoz][ta][xnwoz]> on Friday May 05, 2006 @08:49AM (#15269350)
    Because downloading the JDK or the JRE after installing linux was hard? If it wasnt for this, I wouldnt be periodically using the latest version.
    • Re:Hard.. (Score:3, Insightful)

      Exactly. Especially if you're running multiple versions of Java. What really annoys me is RPMs that expect an RPM-installed Java.
      • Re:Hard.. (Score:3, Interesting)

        by CastrTroy ( 595695 )
        This is what bothers me most about RPM. If RPM didn't install it, then it doesn't exist. Sure you can force the install, but if the package wasn't installed where it was expected to be, then things often won't work properly. It doesn't help that a lot of things aren't available as RPM. I'm using Mandrake(iva) 2006, and it still only has Firefox 1.0.6 available.
        • Re:Hard.. (Score:4, Informative)

          by /ASCII ( 86998 ) on Friday May 05, 2006 @09:18AM (#15269463) Homepage
          That's the fault of lazy packagers, not a problem with RPM itself. You can specify dependencies on a particular file (like /usr/bin/java) insesad of a package if you want to. And if that's not enough (e.g. if you want to allow people installing into /usr/local/ or /opt) you can write little dependency checking scripts at install-time. For example, this snippet makes sure a few X headers are present, regardless of if they are installed in /usr or /usr/X11:

          %define xinclude %( if test -d /usr/X11R6/include; then echo /usr/X11R6/include; else echo /usr/include; fi )
          Requires: %{xinclude}/X11/StringDefs.h, %{xinclude}/X11/Xlib.h

        • Building your own RPMs isn't all that difficult actually.

          Official instructions are here [tldp.org], but you can google for every one in the worlds opinion on how it should be done.

        • RPM (Score:3, Informative)

          by dereference ( 875531 )
          This is what bothers me most about RPM. If RPM didn't install it, then it doesn't exist.

          This must be your lucky day [sun.com]. Sun has an RPM package for download; the self-installer generates the .rpm file.

    • Re:Hard.. (Score:5, Insightful)

      by CastrTroy ( 595695 ) on Friday May 05, 2006 @08:55AM (#15269369)
      I think it has more to do with having the distro do it for you. If we want Joe User to be able to use linux for their desktop needs, then we are going to have to make it as easy as possible for them to use. Of course the people in control of the distro are the ones making the decision. If they don't want to include it because of some ideological values, then that's their business. If they feel the people using the OS has can just install it themselves, then that's their business. But if they're trying to put out an easy to use desktop distro, then they'd probably be smart thinking twice about including it.
    • Because downloading the JDK or the JRE after installing linux was hard?

      If your distro installs the JRE, then it can use an updater written in the Java language for safety. If your distro installs the JRE, then Java will work even if the user can't get broadband without moving.

    • Re:Hard.. (Score:3, Informative)

      by ronmon ( 95471 )
      It's not hard, but it is a pain in the neck. For example, in Gentoo:

      emerge dev-java/sun-jdk

      >>> Emerging (1 of 1) dev-java/sun-jdk-1.5.0.06-r2 to /
      !!! jdk-1_5_0_06-linux-amd64.bin not found in /net/distfiles

      !!! dev-java/sun-jdk-1.5.0.06-r2 has fetch restriction turned on.
      !!! This probably means that this ebuild's files must be downloaded
      !!! manually. See the comments in the ebuild for more information.

      * Please download jdk-1_5_0_06-linux-amd64.bin from:
      http://javashoplm.sun.com/ECom/docs/Welcom

      • Re:Hard.. (Score:3, Interesting)

        by AeroIllini ( 726211 )
        So you have to go there, accept the 'clickwrap' license, download it somewhere, then mv it to your distfiles directory. Unnecessary mumbo jumbo.

        The whole point of the "mumbo jumbo" is to get you to agree to the license terms. This is also the reason why the earlier versions of Firefox 1.5 (compiled, not the binaries) did not have the official branding enabled in Gentoo; it was a licensing issue. As soon as Gentoo got permission from the Mozilla Foundation to distribute the trademarked images in the source,
    • Re:Hard.. (Score:3, Insightful)

      by master_p ( 608214 )
      Not everyone has internet access all the time or fast internet access. Don't forget that Linux is also distributed by magazines, then the Linux CDs are passed around to people that might not have internet access at the time or not have fast internet access.
  • by JoelMeow ( 740794 ) on Friday May 05, 2006 @08:51AM (#15269354) Homepage
    days of downloading Java

    That's what you get for having a slow connection.

  • by Anonymous Coward
    Sadly, this means that Windows will be the only major OS that can't seem to come with Java delivered right out of the box. Maybe they'll address that problem with Vista?
    • Re: (Score:3, Funny)

      Comment removed based on user account deletion
    • by Anonymous Coward
      This really comes down to marketing. Even if Java is useful for a majority of customers, Microsoft will not provide it because Java could diminish the effectiveness of their business strategy.

      This is a dangerous game to play - at what point does Microsoft stop supporting their customers for the sake of their business strategy? Some will say that that time came long ago, and that it is an implicit sign of anti-competetive, monopolistic practices. I disagree - as some could claim that Java is simply not ap
    • Actually, sun has been working to get OEMs (Dell, Gateway, etc.) to bundle the JRE with their systems.
    • As in another comment, Sun may get OEMs to bundle Java with systems they sell that have Windows preinstalled, but it's unlikely that Sun and Microsoft will come together to bundle Java with Windows directly anytime soon. Remember, it was legal issues between the two parties over the now defunct and soon to be EOL'ed Microsoft Java Virtual Machine that forced Microsoft to ditch MSJVM in the first place (rightly so, I think).
    • All joking aside, Windows users actually would stand to benefit the most from open sourcing Java. The Sun JRE, which virtually ALL Java apps are arbitrarily dependent on is one of the worst apps I've ever seen when it comes to memory utilization.

      I've seen Win32 apps consuming 150Mb of RAM.

      If Sun were to open source Java it could open the door to different, better JVMs that might even be able to spoof itself as "Sun JRE" for the myriad of poorly written Java apps that refuse to run on anything else.
      • The Sun JRE, which virtually ALL Java apps are arbitrarily dependent on is one of the worst apps I've ever seen when it comes to memory utilization.

        When was the last time you came across a Java program that required the Sun JRE? I exclusively use the IBM JRE on Linux, and have never had a problem with compatibility.
  • by Edzor ( 744072 ) on Friday May 05, 2006 @08:54AM (#15269366) Journal
    not sure about pervious versions of slack, but 10.2 ISO has it, i dont see the problem way other distro dont include it?

    jre-1_5 [slackware.it]
    • Comment removed (Score:4, Interesting)

      by account_deleted ( 4530225 ) on Friday May 05, 2006 @08:58AM (#15269384)
      Comment removed based on user account deletion
    • i think debian/ubuntu keep away from it because it has an uncomfortable license that doesn't match with the rest of the system ;)

      most debian/gnulinux software is either gpl/lgpl or bsd (or alike) licensed, can be distributed without any restrictions just about anywhere. the license of java which you are supposed to read and accept while downloading and installnig, differs a lot from the "free as in beer" or "even more free than beer" licenses mentioned above.

      for the commercial distros - no idea, but possibly the same issue.
      • by zerblat ( 785 ) <jonas@sk[ ]c.se ['ubi' in gap]> on Friday May 05, 2006 @10:09AM (#15269775) Homepage
        The Binary Code License Agreement [java.com], under which Sun's Java implementations are licensed, only allow you to distribute their software if "[...]you do not distribute additional software intended to replace any component(s) of the Software[...]".

        That means that you can't also distribute e.g. gcj or GNU Classpath. The license isn't exactly clear on whether it means that you can't distribute Sun's JRE together with gcj or whether distributing Sun's software means you can't distribute gcj at all -- ever. It's also not clear exactly what they mean by "software intended to replace any component(s) of the Software". In the worst case, that could apply to any software that performs the same function as some part of the JVM, the byte compiler, the class library etc. Does distributing Swing mean you can't distribute GTK?

    • It's been there for a while. It first appeared in Slackware 8.0 in the contrib portion of the distro:

      Mon Apr 2 15:30:09 PDT 2001
      contrib/java/: Added Java(TM) 2 SDK, Standard Edition,
      Version 1.3.0_02. Thanks to Sun Microsystems for
      allowing us to include this with Slackware.

      It was moved to the official, standard set of Slackware packages in Slackware 9.1:

      Tue Aug 12 12:49:36 PDT 2003
      d/j2sdk-1_4_2-i586-1.tgz: Added Sun's Java(TM) 2 Software Development Kit,

    • SuSE 10 also includes the JRE by default.

  • by CustomDesigned ( 250089 ) <stuart@gathman.org> on Friday May 05, 2006 @08:58AM (#15269385) Homepage Journal
    Sun provides an open spec (actually multiple specs). There are open source implementations of the spec. Sun and others have proprietary implementations. There are applications where the open source implementations are superior (typically small memory and embedded). If you have tons of memory, Sun's Hotspot VM is very fast.

    If there are areas where the specs need improvement to get closer to the "Write Once Run Anywhere" goal, by all means complain about those areas.

    We want multiple competing implementations, both open and proprietary. That said, I could see Sun open sourcing the Java libraries - at least the Java parts. The SDK comes with Sun source for the publically visible parts of libraries. However, the licence precludes using that source in an open source VM. Instead, the GNU classpath project has to rewrite them from the spec.

    Keeping the Sun VM proprietary but opensourcing the libraries seems like a good compromise between maximum interoperability and competition.

    • That is a fantastic idea! I'd love to see that: open source the java.* packages, but leave control of the language and the actual specs in Sun's hands. The best of both worlds.
      • The way I see it, there are three relevant levels of openness here:

        * A standard which is well defined, whose license can not be arbitrarily terminated and is provided to everybody free of charge or at a reasonable cost. (This is the most important one)
        * An open sourced reference implementation of that standard, prefereably released under the BSD licence so anybody can extend it. (This is nice but not crucial)
        * An open standards process. (If the standard is stable and well written, this is not all that impor
        • Actually, Sun is doing the third too. If you want to get involved with the development of the standard, you can. Sun is not doing the second because they don't want there to be incompatible versions that ignore the standards process. This may back fire, because there are likely to be two Free almost-compatible implementations in the near future which are not called Java, but work 90% of the time.

    • by The Warlock ( 701535 ) on Friday May 05, 2006 @09:13AM (#15269449)
      The problem is that the open-source implementations of Java tend to be a version or two behind the official Java, which can be a problem for some Linux users (such as CS students like myself).
      • which can be a problem for some Linux users (such as CS students like myself)

        As a CS student you should be able to get the sun JRE/JDK going on your linux box. (I speak as a former CS student who just did it... (again)...) I found it took about an hour to find useful instructions and less than five minutes to follow them.

        That being said, I agree that having the option of installing a real sun JRE/JDK with apt-get or rpm WITHOUT dropping to the command line or hacking configuration would be a BIG bonus an

        • Sorry, but this is ridiculous.

          apt-get install java-package
          fakeroot make-jpkg jdk-1_5_0_06-linux-i586.bin
          sudo dpkg -i sun-j2sdk1.5_1.5.0+06_i386.deb

          If this took you a whole hour, you are in BIG trouble my friend :-)
        • by eddeye ( 85134 ) on Friday May 05, 2006 @07:51PM (#15274390)
          which can be a problem for some Linux users (such as CS students like myself)
          As a CS student you should be able to get the sun JRE/JDK going on your linux box. (I speak as a former CS student who just did it... (again)...)

          As a former CS student *and* instructor, take my advice: run away from Java as fast as you can. I'm not saying it's a bad langage/environment or doesn't serve some audiences very well. But Java's like cigarettes, starting on them too early stunts your growth.

          CS students need to learn as many different programming approaches and concepts as they can. Procedural languages (C et al), iterative (generators, Python/Ruby), functional (lisp), declarative (prolog), message passing, object oriented, generic programming, closures, static vs dynamic typing, etc. Breadth of exposure to different approaches is crucial to knowing what approach to take with real-world problems. This should be coupled with a depth of understanding of what the system does 'under the covers' at each level. It makes all the difference in the world when facing unexpected problems and differentiates a code monkey from an engineer.

          Unfortunately Java covers only a couple of these areas and none of them particularly well. Standardizing classes on Java is one of the worst things a CS dept can do. If you're stuck in this boat, all I can suggest is play around with other languages every chance you get.

    • by Anonymous Coward
      Keeping the Sun VM proprietary but opensourcing the libraries seems like a good compromise between maximum interoperability and competition.

      Which is exactly why it'll never happen. The giant Java library ensures that, even with a 100% compatible JVM, most Java applications will only run on the Sun runtime. (Especially applications that use "sun.*" or "com.sun.*" packages in open defiance of Sun themselves saying not to do that. But that's beside the point.)

      Sun learned from their experience with Microsoft
      • By having a massive and hard to implement class library, Sun ensures that anyone else trying to create a compatible Java runtime will always be playing catch-up.

        Yeah because being feature-rich is an outright intentional action in order to stop people implementing compatible Java runtimes and class libraries.

        Wasn't there a day in the past when you got some software and thought "wow, it does everything I wanted it to", instead of "OMG this has too much relevant stuff. I wish I would have to code it myself. I
      • by Tim C ( 15259 ) on Friday May 05, 2006 @10:23AM (#15269853)
        Microsoft. When Microsoft had their own JVM implementation, Microsoft added various extra libraries and functionality to their runtime that Sun was missing. Sun responded by sueing

        MS added classes to the java.* package hierarchy, in contravention to the terms of their licence. That's why Sun sued. Had MS put their classes in a com.microsoft package hierarchy like you're supposed to, Sun wouldn't have cared (or had a leg to stand on).

        The restriction was/is in the licence to prevent exactly what started to happen - people started using the classes, and thus were writing code that could only run on MS's VM, which is completely against the core Java ethos of "write once, run anywhere". (Ok, so in practice that's often easier said than done, but this was threatening to make it completely impossible)

        For what it's worth, MS didn't have to stop shipping a VM with Windows; they just had to stop shipping their non-compliant VM. They were perfectly at liberty to remove the offending classes and continue developing a compliant VM. Instead they chose not to do so, shifting their efforts to .NET instead.

        Especially applications that use "sun.*" or "com.sun.*" packages in open defiance of Sun themselves saying not to do that.

        That's a really dumb thing to do if you care about cross-release compatibility. There's no guarantee whatsoever that classes that are present in one release will be present in the next.
      • Which is exactly why it'll never happen. The giant Java library ensures that, even with a 100% compatible JVM, most Java applications will only run on the Sun runtime. (Especially applications that use "sun.*" or "com.sun.*" packages in open defiance of Sun themselves saying not to do that. But that's beside the point.)

        Sorry, but this is plain wrong. Most Java applications will run on any certified JRE of the appropriate version. That is the point of certification of the JDK and JRE! Even some of the lar
    • That's because Mr. Volkerding cares more about his users' experience in providing something that just works, works reliably, and is complete than ideology and software politics.. Slackware has been including xv (a shareware image viewer) since like Slackware 1.0..
    • We already have open source Java
      Yeah, and they don't work correctly. Just yesterday I was helping a person at work with their code. They had a Java program that was doing an LDAP query. It worked fine on other machines but not on one of the test machines. Turns out some JRE called Kaffe was in the path before the Sun JRE. Changing the path to the java executable fixed things.
    • If you have tons of memory, Sun's Hotspot VM is very fast.

      And it is pretty good even if you don't. For example, there is an implementation of Hotspot for J2ME/CLDC that runs in 1MB.
    • If there are areas where the specs need improvement to get closer to the "Write Once Run Anywhere" goal, by all means complain about those areas.
      the problem is twofold.

      1: the java.* and javax.* trees are bloody massive so reimplementing it all is a huge ammount of work
      2: most java developers don't give a fuck about runtime environments other than suns and some of the platform isn't very well documented (just go and have a look at some of the stuff in javax.swing.plaf). The result is that most java apps only
  • Sun's commitement? (Score:5, Interesting)

    by SWroclawski ( 95770 ) <serge@wrocLIONlawski.org minus cat> on Friday May 05, 2006 @08:59AM (#15269389) Homepage
    I remember hearing about two or three weeks ago that Sun said it was committed to "Open Sourcing all of its software, everything they make."- this is from LugRadio and a Sun representative.

    Given this /very/ progressive stance, I don't see why they're stalling when it comes to Java.

    If anything, this slows Java adoption.

    Java was all the rage in the late 90s. Had they made it Free, I think it would have been a tour de force. Now we see competition from simpler technologies. We're learning that we don't need a J2EE infrastructure when a simple Model-View-Controller model with a database backend will do the job just as well, and so on.

    Freeing Java would spread adoption, if nothing else than by including it in every distribution shortly thereafter.

    This new license system isn't good enough, it'll just frustrate people.
    • by fossa ( 212602 ) <pat7.gmx@net> on Friday May 05, 2006 @09:33AM (#15269547) Journal

      (Luke Skywalker stands hands bound on the edge of a plank)

      "Java! This is your last chance. Free yourself, or die."

      (laughter ...but Java the Hutt will soon learn he's too sluggish as he is choked to death by Princess Ruby)

    • by Tim C ( 15259 )
      We're learning that we don't need a J2EE infrastructure when a simple Model-View-Controller model with a database backend will do the job just as well, and so on.

      There's nothing stopping you from implementing that MVC architecture in Java with a servlet container, of course - in fact, in my experience the vast majority of websites that use Java use it in exactly that way.
      • except you'll need to spend 2x the money for all the bloated layers j2ee requires. I work for a VAR, java sells hardware, that's for sure. Of course, some of our clients are waking up and realizing they can't afford java anymore. And I love it when benchmarks "proving" java speed are procedural math codes, do some actual oo stuff and you'll see what a pig it truly is.
    • They're not necessarily stalling. Sun's a big company. It takes a while to pass The Word to all of the middle managers and beat the lawyers into submission.
  • This is great! Now Linux development can equally support the Big Three: Java, .NET (Mono), and the P-languages (plus one R)! The next step ... get it all to run on Parrot [parrotcode.org]! Convergence like none other, bwa ha ha huh!
  • Limits? (Score:4, Insightful)

    by J.Y.Kelly ( 828209 ) on Friday May 05, 2006 @09:00AM (#15269396)
    Unfortunately the article is a bit light on details. It says that Sun are going to make the JRE easier to redistribute but that on it's own isn't enough for many distros. It would also have to be at least able to be repackaged (so it goes somewhere more friendly that the Sun supplied RPM) and preferably modified (to make it play nicer with the rest of the system) before it's really useful.

    Also, it's a shame it seems they're only going to include the JRE. Nice and easy for linux users to run java programs. Shame they won't be able to write any...
  • Java as electricity (Score:5, Interesting)

    by aphaenogaster ( 884935 ) on Friday May 05, 2006 @09:01AM (#15269400)
    Odd analogy, but I guess it kind of makes a little sense maybe... http://www.forbes.com/2006/05/04/sun-microsystems- schwartz-cz_ec_0504schwartz.html?partner=yahootix [forbes.com] In shwartz's words...

    Forbes:

    You're trying to woo customers with free hardware. How do you make them paying customers? You haven't monetized Java proportional to what's out there.
    JShwartz:

    That's a misnomer. Largely an American misnomer. Nearing 1 billion Java handsets.

    Forbes:

    So what's your Java revenue?

    JS:

    Close to $13 billion.

    F:

    That's not money in Sun's pocket, though.

    JS:

    It's like asking a company that produces generators how much of their demand comes from people using electricity. It's 100 percent.

    F:

    But it's about how many customers are paying you for the privilege of using Java.

    S:

    And I'll point out that a billion handsets fuels an enormous market in the telecommunications industry. Java running on Sun's Java Enterprise system, whether it's at American Express or General Electric or Vodafone, is fueling Sun's overall revenue. Asking us how much money we make on Java is like asking Verizon Communications how much money they make on handsets. The fact is that they lose a fortune on handsets, but they make a fortune in subscribers.

    F:

    So are you going to convert Java users to subscription service for Sun?

    S:

    Partially, we're already doing that. American Express runs on the Java Enterprise system. That's per employee subscription for core middleware for Sun. My broader point is that Java ensures Sun has access to an open market. Java allows us to reach out to customers who don't run on Sun hardware and ensure we can serve them wherever they may be--whether it's on a Dell box or HP box or in an IBM customer base.

    Again, it's hard to explain to people. Here's an analogy. With the advent of electricity, Thomas Edison tried to patent a lightbulb so that you would have to use his lightbulbs if you used his dynamo. That strategy obviously failed. And what emerged was the standard plug. Asking Sun the value of Java is like asking GE--which is, I think, the largest manufacturer of power turbines in the world--what the value of the standard plug is. It ensures they can serve a global marketplace. So if you asked them what's the value of the plug, how would they respond?

    Here are some stats on Java: There are more than 1 billion Java cards in the marketplace, securing everything from set-top boxes to handsets. There are more than a billion Java handsets, all driving demand for network infrastructure. There are nearly 1,000 members of the Java community process, who collectively contribute to the standard called "Java." It is the default standard for set-top boxes in Brazil. So what will the infrastructure opportunity be in Brazil to serve 100 million Java-enabled set-top boxes? I promise you it will be enormous, and Sun will be among many participants that can serve that demand.
    • by Zigurd ( 3528 )
      Schwartz is right, to the extent he can be at this time: Sun does benefit from Java.

      The interviewer, however, has a point that Schwartz did not address: It is equally clear that Sun could benefit more from Java.

      Schwartz brings up mobile Java. Sun won by default: Qualcomm keeps their application environment on their chips, and Microsoft keeps their's on their OS. Schwartz has no answer to how this victory is monetized. There are some obvious missed opportunities in mobile commerce servers, for example.

      If Sun
  • This is the kind of thing you'd like to reward a company for. All companies should have a comment submission box where you can click, "I totally dig what you just did, here's my dollar that says I really mean it." ... is that a crazy idea? I mean, in all seriousness. The dollar is the only vote an american really has.
  • by Chris Pimlott ( 16212 ) on Friday May 05, 2006 @09:08AM (#15269427)
    Section 5.3 [debian.org] of the Debian Java FAQ sums up the present licensing issues that prevent Debian from including Sun Java.
  • by johnnnyboy ( 15145 ) on Friday May 05, 2006 @09:09AM (#15269434) Homepage

    The more I hear calls that Java to be more open source the more I wish all these Java libraries worked like the way CPAN does.

    CPAN is great and its what keeps Perl relevant and it works well for the Perl community. All these java libraries bundled with the JDK should be more modular with a lean core distro and then the rest can be organized and installed as modules.

    And like everything CPAN all these modules will be peer reviewed by other Java developers in the open source and corporate worlds.

    Ah, one can only dream.

    • One of the best traits about java is the fact that there is a wide variety of standardized core libraries that are consistant with the JRE version. Anytime I have to install a perl script I cringe at having to install a ton of random libraries through CPAN.
      • But...that's not true.

        ORM, RPC, IoC, and many other TLAs are only supported by third party stuff.

        And that stuff gets installed using Ant or Maven...which are very difficult to get working right with a package management system.

        Finally, the fact that Java packages are a lot more willing to change their APIs in minor versions than non-java packages are, and you have a portability crisis If you want to use two different java programs that use different versions of the same library, then you have to play monke
    • All these java libraries bundled with the JDK should be more modular with a lean core distro and then the rest can be organized and installed as modules.

      So you mean that the distribution should decide which modules/classes it should omit?

      That could cripple the standard platform of Java modules developers can depend on. It could cause worst-case scenario's like this one [plan99.net], quoting:

      Debian has packaged Wine in a way different to upstream, and this can cause extremely subtle bugs. One incident that sticks i

    • Dumb idea, and that is why you aren't in charge of these things. One of the biggest pains in the ass with perl software is that whenever you run it you have to read a 20 page reamde saying "Before you run this program, you need to run this list of commands in this order so you can install the dependencies." In good scenarios you just run a script first, or in some circumstances you can use the distro's package management, but regardless it is a pain in the ass. Java's "everything and the kitchen sink" appro
    • I wish all these Java libraries worked like the way CPAN does.

      Do you mean you wish Java libraries worked like CPAN, in the way Maven [apache.org] and its automatic library repository works or in the way the JPackage [jpackage.org] repository works?
  • foster? (Score:4, Insightful)

    by dghcasp ( 459766 ) on Friday May 05, 2006 @09:15AM (#15269456)

    ... advocates say [open-souring Java] would foster innovative open-source development.

    Because there are so few innovative open source java projects right now? Heck, I can hardly keep track.

    Leaving aside the politics of open source, and the "I can't play with your toys" argument, the main issue here seems to be the license incompatability that keeps Java from being bundled with the 267 different Linux distributions.

    If people want to be innovative, how about working to unify the basic functionality of all those distributions, specifically one common, simple way that works on all distributions and architectures to install 3rd party packages, like, say, Java?

    ObMetaDig: And besides, why do you care? Every time I see java on /., the whole thread seems to be "it's slow / no it isn't / GC sucks / no it doesn't / .NET rules / no it doesn't"

    • Re:foster? (Score:3, Interesting)

      by glesga_kiss ( 596639 )
      I couldn't find the original Slashdot article or the current figures but the following is from Nov 2005 [jroller.com]:

      Java history was made today!

      Today Java overtook C++ as the language with most projects on SourceForge! Here is the current list for languages with more than 1000 projects:

      1. Java (16738 projects)
      2. C++ (16731 projects)
      3. C (15934 projects)
      4. PHP (12175 projects)
      5. Perl (6209 projects)
      6. Python (4542 projects)

  • by gvc ( 167165 ) on Friday May 05, 2006 @09:38AM (#15269576)
    I don't see how this is any different from tainted binary kernel drivers. They'll allow redistribution of the JRE run-time environment. Big deal.

    If they allowed redistribution of JDK compiler and libraries, we'd be making progress.

    Nothing to see here. Move along.
  • 64-bit? (Score:4, Insightful)

    by escay ( 923320 ) on Friday May 05, 2006 @09:43AM (#15269607) Journal
    well they could start with providing the mozilla-firefox java plugin for amd64 systems on linux...libjavaplugin.so, anyone?
  • I'd Be Happy (Score:3, Interesting)

    by Greyfox ( 87712 ) on Friday May 05, 2006 @09:52AM (#15269657) Homepage Journal
    If they'd just fix some broke-ass things about the language. Seems like every time I run up against a limitation in the language, I find a bug open from 1998 complaining about the problem and either closed wontfix or "We'll fix that in a future release of java" and then they don't.

    Three recent thorns in my side:

    The Process object's destroy method sends a SIGINT or some such rot to the child process, which may or may not kill the child process. There's no way to send a SIGKILL, no way to get the PID of the process, no way to set the process group and no way to get or kill children of the child process.

    There's no way to get OS-Specific permission settings on a File. For that reason if you try to archive some files in Java using an InputStream that takes Files, you'll lose the permissions settings on them and the files will restored with something both generic and useless like 644. They make a halfhearted attempt to address this in 1.5, but it's still useless.

    It would appear that the only way to get disk space left on the volume is to open a file and start writing 1 byte at a time until you get an IO Exception.

    It's deficiencies like this (And the ~50MB VM overhead) that make Java a poor choice for system programming tasks, but the robustness of the language design itself could be so easily changed to address these issues. The fact that it hasn't and that all of these issues have been around for over half a decade lead me to believe that Sun isn't really serious about the language and probably shouldn't be in charge of the standard, either.

    • Not defining a standard library location into which the sysadmin can place locally-required libraries for his users to share is high on my list of jaw-dropping omissions. Having to maintain a 4KB CLASSPATH string for every application is not my idea of robust design.
      • Put jarfiles common to all users in in $JAVA_HOME/jre/lib/etc.

        Or put symlinks to common jarfiles in that location (my own preference).

        • Thank you. 'twould be nice if this were documented somewhere or, if it is, had I been able to find it.
          • Re:I'd Be Happy (Score:3, Informative)

            by mark-t ( 151149 )
            Actually, I just noticed a small typo in the line.... it should be Put jarfiles common to all users in in $JAVA_HOME/jre/lib/ext.

            I didn't realize I had typed etc instead of ext until I read your reply. My bad. Sorry.

    • Re:I'd Be Happy (Score:5, Informative)

      by LarsWestergren ( 9033 ) on Friday May 05, 2006 @10:27AM (#15269882) Homepage Journal
      There's no way to get OS-Specific permission settings on a File. For that reason if you try to archive some files in Java using an InputStream that takes Files, you'll lose the permissions settings on them and the files will restored with something both generic and useless like 644. They make a halfhearted attempt to address this in 1.5, but it's still useless.

      It would appear that the only way to get disk space left on the volume is to open a file and start writing 1 byte at a time until you get an IO Exception.


      These two are finally fixed [sun.com] in Mustang. I agree it has taken long though:

          Three new methods have been added to java.io.File class:

                getFreeSpace()
                getUsableSpace()
                getTotalSpace()
      [...]

        Changing File Attributes:

        In Mustang the java.io.File API provides access to the file attributes for changing its readability, ability to write and ability to make it executable. Check out the following methods for playing around with file attributes:

        Changing readability: owner-only, owner or everybody
        Making it writable or read-only: owner-only, owner or everybody
        Making it executable or not executable: owner-only, owner or everybody

  • Why does Sun have to open source the JRE in order to have it bundled?
    I don't remember seeing anything in the GPL that says it can't share disk space with non-GPL binaries.

    Is this what is meant by "choice"?

    • They don't have to open source it. They need to stop requiring that it be downloaded directly from their servers and that the user view and affirmatively accept the license for every installation.
    • From the Debian FAQ entries, it doesn't need to be open-sourced, but it does need a license which doesn't prevent it from being bundled with other software that replaces any function of JVM, which allows it to be distributed other than for the sole purpose of running an application or applet distributed with it, and doesn't require you to agree to indemnify and defend Sun from any lawsuits by the people you distribute it to, before it can be bundled. The GPL isn't an issue. Sun's license is the issue.
  • Installing Java on Linux is easy as pie. Try installing it on OpenBSD....
  • by benmhall ( 9092 ) on Friday May 05, 2006 @10:06AM (#15269752) Homepage Journal
    I've never really understood why Sun doesn't just dual-license the Java VM and libraries like it does with OpenOffice. This would allow Linux distributions to include both the JDK and JRE and wouldn't preclude commercial developments. This wouldn't be that different from what Trolltech does with Qt. With Qt, this limits commercial KDE development, but Java already enjoys strong commercial support. If they GPL'd (not LGPL) the JDK, they would open doors to the Open Source community while still supporting their commercial contracts.

    I wouldn't think that forks would be a big problem either, as everyone would likely stick to Sun's JDK by default. I certainly haven't run into IBM's JVM very often and one needs to look no further than Mozilla, OpenOffice.org and Qt for evidence that dual-licensing doesn't necessarily lead to uncontrolled forks.

    The truly bizarre thing to me is that this hasn't already happened. It's not like Sun is trying to keep Java sources secret. They've already exposed them to the world with their fairly liberal research license.

    Mayber things will change. I'm reminded of Eric Sink's comment on Slashdot years ago regarding open sourcing OOo:

    "The only glimmer of hope has been Sun, which seems to have a practice of being smart during the even-numbered years and downright silly during the odd-numbered ones."

  • Non issue? (Score:3, Interesting)

    by Espectr0 ( 577637 ) on Friday May 05, 2006 @12:08PM (#15270648) Journal
    Slackware has bundled java for years. Why didn't anyone else? Is/was it illegal?
  • by aCapitalist ( 552761 ) on Friday May 05, 2006 @12:15PM (#15270717)
    It's nice that they've made this move, but I don't see how this really changes much. The server side guys never had a problem with downloading Java. I can only assume that this is a move for the desktop.

    The problem (as I see it), is that it's too late for any kind of java desktop resurgence. How come Sun never produced any kind of Java Gnome/Gtk+ apps? They do employee Gnome contributors and Gnome is their desktop. Oh right....Swing is enough for everyone,*rollseyes*. Maybe four years ago if they had gotten behind Java gtk+, and made this move things would be different, but much of the open source desktop developers have moved on to Ruby, Python, and Mono. And there's still a lot of development done in C/C++. Even on the server side, many people are moving to LAMP+Ruby.

    So my question is what is Sun's reasoning for doing it now?

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Working...