Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Sun Releases First GPLed Java Source

Posted by CowboyNeal on Fri Dec 22, 2006 07:21 AM
from the beginning-of-an-era dept.
An anonymous reader writes "You can now get GPLed JVM sources from Sun. Everyone seemed to be expecting the desktop version (J2SE) but J2ME has been released first. It looks to be buildable for Linux x86, MIPS, and ARM platforms. Sun now calls it 'phoneME.' Enjoy."
+ -
story

Related Stories

[+] Sun Completes Java Core Tech Open-Sourcing 141 comments
MsManhattan writes "A year after announcing its plans, Sun Microsystems has made almost all of the core technology in Java available as open-source software under the GNU general public license version 2 (GPLv2). However, some of the code remains 'encumbered'; that is, Sun doesn't have sufficient rights to release it under GPLv2, and the company is requesting the open-source community's help in resolving these issues. Rich Sands, community marketing manager for OpenJDK community at Sun, would not say what percentage of Java's 6.5 million lines of code are encumbered, but explained that it is largely Java 2D graphics technology, such as font and graphics rasterizing."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Anonymous Coward on Friday December 22 2006, @07:47AM (#17335662)
    Looks like this was released back in November with the full Java GPL announcement according to the official announcement [sun.com].

    And people already started hacking it and combining it with all kinds of interesting existing free java projects to product MIDPath [thenesis.org]

    Seems the GNU Classpath, Kaffe, GCJ, etc projects really want to Collaborate [wildebeest.org] and work together [wildebeest.org] with Sun according to their latest release notes [gnu.org]. 2007 might be a pretty interesting year for Java and GNU/Linux (and mobile devices!)

  • by dwalsh (87765) on Friday December 22 2006, @08:37AM (#17335896)
    Congratulations to the Sun people who have made this a reality.

    They are freeing up the crown jewels, and the significance of that fact should not be underestimated. Free as in 'gratis' and free as in 'libre' [wikipedia.org].

    I am not a Sun employee, but I am a Java dev., and I would like to remind people of Sun's contributions to open source over the years. While the press communications of executives have muddied the waters, Sun have done more in the past for open source than a certain "Think Free" company. That company pressed for open sourcing Java and then bitched about the choice of the GPL.

    I would love to see the source to Websphere (not the Geronimo 'Websphere' product, but the real deal).

    ... for laughs if nothing else.

    • by tygerstripes (832644) on Friday December 22 2006, @08:50AM (#17335960)
      Just wanted to say "hear hear". It took 20 posts before somebody actually had the decency to say Thank-you-this-is-a-good-thing, most of those 20 straying into completely niche related topics. I'm not saying they weren't all relevant or interesting points, but thanks for actually saying thanks.

      As far as I'm concerned: the short-term impact of this will be decent as people start getting their teeth into the source (as they have done since November), but the long-term impact will be fucking huge. I don't have a lot of personal experience, but this announcement combined with the fact that so many CS degrees start with OOP by teaching in Java means that people will routinely be encouraged to appreciate the power of FOSS from the start, before they get used to the limitations that its absence imposes.

      To reiterate: This-Is-A-Good-Thing.

  • requirements: (Score:5, Informative)

    by DrSkwid (118965) on Friday December 22 2006, @09:07AM (#17336040) Homepage Journal
    To properly build executables for the Linux/ARM target platform, a Linux/i386 build platform must meet the following requirements:

            * Red Hat Linux distribution version 7.2 - 9.0
            * Java 2 Platform, Standard Edition (J2SE(TM)) Development Kit (JDK(TM)) version 1.4.2
            * GNU Make version 3.79.1 or later
            * GNU Cross Compiler (GCC) 3.4.6 or later
            * Doxygen version 1.4.1
            * Development Kit for the Java Card(TM) Platform 2.2.1

    To set up the Linux/i386 build environment, you must do the following things:

            * Acquire Monta Vista Developer Tools
            * Set Linux platform environment variables

    Acquiring Monta Vista Developer Tools

    To build phoneME Feature software for the Linux/ARM (P2 board) target platform, you must acquire the MontaVista CEE 3.1 ADK developer tools. [mvista.com]
    • Re:requirements: (Score:5, Insightful)

      by lisaparratt (752068) on Friday December 22 2006, @09:48AM (#17336290)
      Welcome to the Real World of Embedded.

      Nearly everything is targetted toward Monta Vista, these days. Being fair on them, it's because they were one of the few embedded Linux distributions that managed to put together something with all the neccessary patches to be actually capable of performing well in an embedded scenario.
  • Thank you Sun (Score:5, Insightful)

    by wikinerd (809585) on Friday December 22 2006, @10:47AM (#17336712) Journal
    I am very happy that Sun Microsystems [sun.com] open sourced its Java and OpenSolaris products. If I buy my own server hardware, I will certainly prefer Sun. Contrast this with Microsoft, which is known for its Embrace-Extend-and-Extinguish practices, its preference to its own shared source licences for the very few lines of code that they ever made public, their aggressive hiring of some open-source people (why? to silence them with dollars?), and shadowy agreements with GNU/Linux vendors. Sun initially tried to use CDDL, but now took a bold step by adopting GPL and releasing actual, useful, working code under it. This means that Sun has open-minded people in its management.
    • Pfft, you've got the source, get to work!

      And I also want this running on the Super Nintendo this time tomorrow, *snap *snap
      • And I also want this running on the Super Nintendo this time tomorrow, *snap *snap

        To be serious for a moment, I honestly hope that this encourages ports to the Wii, XBox 360, and PS3. Java is an extremely capable game programming language at this point, and could potentially save programmers a great deal of development and debugging time. In fact, the only thing that's been holding developers back from using Java is that it doesn't port to the major consoles. If that were to change...
    • by IversenX (713302) on Friday December 22 2006, @08:02AM (#17335714) Homepage
      You are really, really, really comparing apples to oranges here.

      Mono is comparable, yes.

      However, Qt, GTK and wxWidgets are all just GUI toolkits! You still need a programming
      language (Pascal, C++, Perl, even Java(!)) to use these. Installation will be easier,
      though. I'm personally looking forward to "apt-get install sun-java" or somesuch.

      Also, it will soon (when J2SE comes out) be possible to write better integration with existing
      apps, such as better (faster, more modern) browser applet plugins. That, I'm looking
      forward to.

      (Oh, and now that the sources aer GPLed, it should be really easy to make this thing run on *BSD if it doesn't already)
      • While I applaud the Mono team for all their hard work, it is not comparable to Java. Hell, Microsoft's .Net is not comparable to Java yet. With Java, you have a 10+ year old tried-and-true platform. You have 10+ years worth of class libraries written, most Open Source, that eliminate 50%-75% of your workload when writing any application..

        Sure, .Net does some things better than Java, like Windowing. But Mono's Windows.Forms is brand new and hardly what I could call enterprise-ready.
        • While I applaud the Mono team for all their hard work, it is not comparable to Java. Hell, Microsoft's .Net is not comparable to Java yet. With Java, you have a 10+ year old tried-and-true platform. You have 10+ years worth of class libraries written, most Open Source, that eliminate 50%-75% of your workload when writing any application..

          Sure, .Net does some things better than Java, like Windowing. But Mono's Windows.Forms is brand new and hardly what I could call enterprise-ready.
          And You have 10+ years of waiting for java apps to launch!
          • by repruhsent (672799) on Friday December 22 2006, @09:50AM (#17336302) Homepage Journal
            The 90s called; they want their joke back.
                  • by Roman Coder (413112) on Friday December 22 2006, @03:09PM (#17340822)

                    Java is an extremely poor choice of language for desktop applications and high-concurrency network daemons. That is Java's weakness. Do not use it for that kind of application -- it will never come close to C++ in that area. Its strengths generally lie in areas where the overhead of the class libraries do not come into play so heavily -- some server-side work and servlets, and the stripped-down mobile version (that was released today).
                    As someone who makes his (good) income writing desktop applications in Java SE (Swing) for Fortune 100 companies, I would have to strongly disagree with this (and not just because I want to keep paying my bills either! :p ).

                    I (as a contractor) come to a customer site, and see crappy Swing-specific code written. Its usually the developer not knowing how to deal with multi-thread programming (event dispatch thread, etc.). I rewrite the app, it goes into production, and the user base loves it. They click on a single web link to start their app, and automatically get updates when new versions come out. They can run it on multiple OSs too (music industry companies use lots of Macs (for example)). Its performance is comperable to other apps running on their OS/desktop.

                    Java (and Swing, or if you prefer SWT) is more than fast enough to do the job, is very powerful and is allot easier to write to than 3GL languages. But like with any tool (or weapon), you need to know how to use it to use it effectively. And that can be said of any computing language, both 3GL and well as 4GL.

                    I don't mean to be insulting, but it seems like you really don't know what you are talking about. I would even argue that (especially for businesses) it is the BEST choice of language to write applications in. No idea about using it for writing a game and such, but if you're looking for a 4GL (PowerBuilder) type replacement, its the best out there (even though its really a 3 1/2GL language).
        • by Shaper_pmp (825142) on Friday December 22 2006, @09:29AM (#17336176)
          "Comparable" != "identical to"

          Comparable means you can compare the two things - one might be wonderful and the other total shit, but they exist on the same spectrum.

          Apples and oranges are (canonically) not comparable because they're different fruit, so they have different criteria to be fairly judged on.

          You can compare a nice apple with, say, a shitty, maggot-ridden one - they both have the same criteria, so comparison is valid.

          So, on the basis they're both managed programming environments, both compile to bytecode, both tackle the same kinds of tasks in a similar way, you can compare Mono, .NET and Java.

          You might believe one is better than the others, but that doesn't make them incomparable.
          • by molarmass192 (608071) on Friday December 22 2006, @09:17AM (#17336096) Homepage Journal
            Java is hardly what I would call enterprise ready either.

            Man ... that's a +5 Funny if I've ever read one. You obviously don't work in an "enterprise". Take it from someone who does (telco), Java is used in massive deployments where Mono/.Net doesn't even make the faintest blip on the radar. There are production Java apps running with 5-9 uptimes that have been going for years.
              • by samkass (174571) on Friday December 22 2006, @09:39AM (#17336244) Homepage Journal
                A language and toolkit can't compensate for the people who build and maintain the software. Java is easily the best language out there for writing stable, maintainable systems if you use the right tools and know your domain. .NET isn't bad, but IMHO its one big advantage over Java-- the ease with which one can integrate "native" code-- is also a big weakness in potential stability.

                • by jimfrost (58153) * <jimf@frostbytes.com> on Friday December 22 2006, @11:05AM (#17336868) Homepage
                  Frankly speaking, .NET is a Java fork. Right down to the bytecode and up through the class libraries. If you are familiar with JDK 1.1 class libraries you'll find practically everything in them in .NET, usually with only package name and method capitalization changes. .NET added a lot, particularly in terms of XML, SOAP, HTTP, and GUI support, and fixed some seriously stupid stuff in Java like classloaders, but it really is a fork.

                  It's kind of amusing, when you think about it, that what Sun really got out of their lawsuit against Microsoft for their (really, really minor, especially relative to stuff like what Netscape did) modifications to Java was a pure competitor in .NET.

                  You mention .NET's ability to easily (I'd say "relatively easily") link to native code as a big detriment, but in many .NET implementations that's not used at all. It's easier to work with disparate code like that through a SOAP or database interface. In practice you see a lot of .NET front-ends to traditional servers via a SOAP integration. You see less of it used as a replacement for traditional MFC code, the kind of thing where such integration would be most useful.

                  But getting back to the enterprise, .NET's largest problem in terms of enterprise software is not that it's less mature than Java (in many ways I'd say that Microsoft took the good stuff from Java and improved it a lot) but rather that it's locked to Windows. Maybe you haven't noticed, but Windows is not a very good server operating system -- not very reliable, not very fast (except in very specialized situations), certainly not scalable. It's all very well and good that you can drop a couple of hundred boxes in there to scale to huge applications, but when you could run the same application on a single Sun you're really not making a cost-effective choice. (I wish I were making that up, but it is actually pretty typical to be able to replace as many as 100 Windows servers with a midsize Sun or two, and that is true not only of stuff like IIS/ASPX versus Apache/whatever that are differentiated by more than OS but also for directly comparable stuff like databases and ETL). Push Windows hard and it will break, often. It's nuts to put it in critical places (although that is done, a LOT, and people pay the price in ongoing maintenance).

                  Having said that, .NET is probably the single best GUI implementation framework I've seen yet (although that may be damning it with faint praise), and Windows, at least aside from the malware issue, is a pretty fine desktop. In that domain it shows what Java could have been if Sun had been even remotely competent (rather than giving us stuff like AWT and the Swing abomination). We're going to see a lot of .NET on the desktop because it is pretty much best-of-breed. More power to it.

                  Java is today, and has been since at least the late '90s, often used in enterprise situations. Whether or not it's appropriate in a lot of those situations is debatable, but it is deeply integrated into the core operations of a lot of companies at this point. Personally I feel that JMS is not very good at its job and J2EE as a whole is a steaming pile of dung designed by people who wouldn't know a good application architecture if it ran over their foot, but Java as a whole and these things in particular are out there and being used by a lot of people -- and at least in some cases doing a good job.

                  It is certainly possible to build robust, reasonably efficient large-scale Java applications. It is even easier to do that in Java than it is in C++, especially if you avoid some of the more ridiculous parts of J2EE. But that doesn't mean it's easy to build that kind of thing, and as you might expect there are a large number of really awful Java applications out there (just as the majority of large applications built on all the other languages out

                • by Tmack (593755) on Friday December 22 2006, @01:03PM (#17338640) Homepage Journal

                  I think it's the steaming pile of bad programmers that you're having problems with, not Java.

                  > Actually, I do, and I am forced to work with the steaming pile all the time

                  I fall into the "work for a Telco and have to deal with steaming piles of java" category as well. Yes, the developers have something to do with it, but its also the Java mentality of those developers, as well as a few wonderful quirks of the language and its environment. For starters, it seems, for our dev team at least, anything can be done in the Java world if you throw enough $$ at a "platform" or "Framework" and then spend the next several years with large teams of developers and outsourced help (India) to find that the platform/framework you bought cant actually do anything you bought it for (buzzwords), so another one must be bought to solve all the problems (rinse/repeat). They also like to over develop stuff, writing full-blown "feature" filled aps where a single line of cron and/or 5 lines of perl would suffice, and spend the next few years debugging it and restarting it every time it crashes (nightly for most). Java has also somehow managed to become the ONLY SOX compliant language in the eyes of management, possibly due to the dev team, requiring SOX related stuff (which becomes whatever someone feels is somewhat related to SOX in any remote fassion) to be put into a Java wrapper if its not already Java based so that their Java platforms can tickle it all they want.

                  As for the Java platform itself, one of the most common things done in my group (system ops) with systems is restarting Java aps and Java engines. Why? The ap breaks or tickles some Java bug. One nice feature in Java (or Tomcat or JBoss) we know about because of specific breakage it causes is that it keeps its own cache of DNS. The only problem being it ignores TTL and the whole thing has to be reloaded to refresh that cache. Then there are the other Java bugs that cause breakage to the bewilderment of our dev team. Load a page, it works, go back and try again a few minutes later and it crashes. Most likely a poorly written ap causing some memory buffer to overflow, but wasnt Java written to handle that sort of stuff internally so the app dev team doesnt have to worry with it??

                  People might see it as Enterprise App worthy, but I think it has long gone the way of PHP, where most developers have gotten lazy and sloppy. I have used it in the past, though I currently use Perl for a good number of reasons. Like any language, it has its place.

                  Tm

    • Re: (Score:3, Informative)

      "Where's the love for FreeBSD, OpenBSD, and NetBSD?"

      Have you actually tried to compile it? I compile for my architecture (64) all the time with things that aren't made to support it. Sometimes I have to make small changes to strings, but it can't be THAT much worse installing on BSD.
    • by bobaferret (513897) on Friday December 22 2006, @09:37AM (#17336228)
      The quality of the code varies from source to source. Thus making it sub par. Their documentation is okay, since it's produced from the source code and is shown to the public. Atleast on the .java source. But overall I think their code it crap, but not nearly as bad as Mozilla was. The really irritating thing with the rt.jar source code, which has always been viewable, is that they don't follow their own java formatting conventions. There's going to be a lot of available "Janitorial" positions available once all the code get realeased in March (I think they said march). The only thing that really worries me is the JCP process. Linux works well, because in has a benevolent dictator at the top. Translation, it has a vision/direction. JCP's are commitiees, and that will slow down OS/FOSS development efforts. I imagine/hope that ClassPath will stick around and add features/ be the eqivilent of a development branch. There are things I'd like to see added to that language that would never make it through a commitiee (I just can't spell that word this morning, sorry). But by having a development unstable branch, maybe some of these things can be tried out and proven in the field, then added back into the mainline trunk. The JCP seems to work well, but I'm really curious to see if it can keep up with OS development.