Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Sun Lowers Barriers to Open-Source Java

Posted by Zonk on Fri Aug 10, 2007 10:18 AM
from the coffee-making-made-easy dept.
Programming Java Software IT Technology
Shyane writes "Sun Microsystems is making it easier for open-source programmers to ensure their Java versions meet the company's compatibility requirements, but the deal extends only to those involved in Sun's own open-source Java project. The program grants access to its Java Technology Compatibility Kit to anyone with an open-source Java project that is based substantially on Sun's open-source Java software and governed by the GPL. Programmers need access to the test kit to prove that a project is in compliance with the Java specification. Projects that pass Sun's compatibility kit tests also can use the official Java logos for free."
+ -
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."
[+] Technology: Sun Debuts Java 'iPhone' 195 comments
An anonymous reader writes to tell us that this week at the JavaOne Conference, Sun debuted it's answer to the iPhone. While it is still months away from being a reality this phone is set to put them in direct competition with some of the top cellphone vendors. "Java Mobile FX is "a complete desktop-scale environment that puts the network in your hand," said Richard Green, executive vice president of Sun's software group, announcing the product in his keynote address. Sun ported the Savaje code to a Linux kernel and is expanding the applications programming interfaces and set of developer tools that will ship with it. It plans to make the code available on other platforms in the future. Sun has no licensees for Java Mobile FX yet. However, it is in conversations with carriers and handset makers now and hopes to see cellphones using the software ship in early 2008. "
Submission: Sun lowers barriers to open-source Java by Anonymous Coward
[+] Sun to Fully Open Source Java 374 comments
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.
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.

Sun Lowers Barriers to Open-Source Java 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Riots break out across the world... (Score:5, Funny)

    by vigmeister (1112659) on Friday August 10 2007, @10:19AM (#20183247)
    as programmers discover that the test suite only runs on Windows.

    Cheers!

  • Openness! (Score:3, Informative)

    by kevmatic (1133523) on Friday August 10 2007, @10:30AM (#20183375)
    Finally, "open, cross-platform" Java is beginning to become open. Now I just hope it becomes more cross platform, rather than "Windows, Mac, x86 Linux and whatever-you-spend-a-million-hours-developing-an-i mplementation-for."

    Seriously, I was pissed when I found out just how bad Java support is for Linux PPC. I couldn't get an iMac to go to Yahoo! games for my grandma. :(

    Now all we need is cross-platform Flash.
    • If it's on more than one platform, it's cross-platform. That doesn't mean that it will automatically support every processor/OS combo ever made.. do you mean now all the Linux PPC users is Linux PPC flash? Not trying to troll, just pointing out that if you want stuff available on your own platform, sometimes you're going to have to do it yourself - can't just rely on everyone else to do stuff for you. I don't know if that's possible in this case, but if it really is "open" then it should be.
      • To be fair, Java was (at least initially) heavily marketed as "write once, run anywhere". It's pretty obvious that the language doesn't come anywhere near the hype in that regard.

        • Re:Openness! (Score:4, Insightful)

          by LWATCDR (28044) on Friday August 10 2007, @10:58AM (#20183809) Homepage Journal
          Yes it really has. I have run the same Java application on Windows, Linux, and Mac OS/X. If there is a good JVM you have a very good shot at your java application working.
          Yes you have to have a JVM but that is sort of a given.
        • Yep, that's never going to be possible without the appropriate VM/emulator/decoder for every system, whether in hardware or software. Java was a cool idea, but I've never liked it in practice.
        • Yes, and Java can run anywhere you have a JVM. "write once, run anywhere" was a marketing phrase, certainly nobody believed it would run on any system anywhere without a VM. You can implement the JVM on virtually any hardware and any OS, just because a platform doesn't have a JVM for it yet doesn't mean a Java application you "write once" won't run there once they do have a JVM.
        • I suppose there will be './configure && make && make install' versions of both the JDK and the JRE.

          Eventually.

    • Seriously, I was pissed when I found out just how bad Java support is for Linux PPC. I couldn't get an iMac to go to Yahoo! games for my grandma. :(

      You gave your own grandma an iMac and then put Linux on it?

      Why do you hate your grandma?

      • I know, if Grandma wanted Linux you should have bought her a all in one box from PCclub and with the money you saved bought her flowers every week for two months.
      • It could have been one of the old G3 (CRT) iMacs. These ran MacOS 9 well, but struggle with OS X. Putting a lightweight *NIX on them might be a good option.

        • Actually, I bought an old G3 for the kids and through 10.4 and an extra 512MB of memory on it. It runs like a champ. If Grandma wants to run Doom 3, maybe not so much, but web and email and everything else she'd be likely to do with Linux on the same hardware should be fine.

    • Re:Openness! (Score:4, Informative)

      by cerelib (903469) on Friday August 10 2007, @11:01AM (#20183859)
      IBM has a free version of Java, I believe up to 5.0, for Linux on PPC. I have it running on an openSUSE PowerMac. I believe this [ibm.com] is the site to look at. They don't say PPC, but you want the pSeries version (in both 32 and 64 bit varieties).
    • Forget Linux, Java works much better on Windows than on Solaris.
      I found Java on Solaris to be rather buggy.
    • In my experience the Yahoo! games don't run properly with the Sun JVM on windows. They do seem to run well on windows using the MS JVM.

      I've tried to play some of those games against her using my linux laptop and it was hopeless. Instead we play Tetris attack using a snes over the network.
      • IBM made most of their JVMs much harder to find, or even pulled them completely about a year ago. Now I think you can only get the AIX and OS/390 versions separately, for everything else you have to get WebSphere or something else with it bundled for that platform.

      • Re: (Score:2, Interesting)

        by Rexdude (747457)
        I'm part of the Java6 dev team..in addition to linux, IBM Java is also available for the following platforms-
        • Windows (IA32 and AMD64)
        • Linux(IA32,AMD64,PowerPC 32/64)
        • z/OS(31 and 64 bit-yup,not a typo, z/OS uses a 31 bit addressing scheme)
        • AIX (PowerPC 32/64)
        • z/Linux 31 and 64 (Linux on system z)
        • See here [ibm.com] for the early release program.

      • Why the vile comment? It makes you look like an idiot, especially when you're obviously wrong. Let me list the ways:

        1. While PPC may be in your opinion obsolete on the desktop, it is still one of the platforms of choice for embedded applications. BTW, plenty of business cases for PPC too. I personally like the ppc405gpr for low power applications, and look forward to the ppc405ez when it becomes available. Tivo likes the PPC too, but I know Tivo is not exactly popular with the GPL guys.

        2. We don't have to

        • My argument is "vile"? You're the one that's making personal comments.

          • LOL

            Maybe abrasive is a more appropriate term...

            • I'll buy "abrasive". That's a pretty good description of my personality. But my personality traits have nothing to do with the validity of my arguments. Nor do they justify your using the word "idiot".

              As long as we're discussion personalities, go look up the word "patronizing".

              Anyway, now that we've thoroughly abused each other, let's look at your arguments:

              1. While PPC may be in your opinion obsolete on the desktop, it is still one of the platforms of choice for embedded applications.

              Fine, I should have qu

  • I so want a native Java compiler. I like Java but the loading of the runtime is a bit of a pain. The option of compiling a native version would be very nice.
    • "Loading the runtime" basically amounts to transferring the libraries from disk to RAM. So startup time has nothing to do with the supposed efficiency gain for native code compared to byte codes. (Which is mostly not true anyway, but that's another issue.) What it does have to do with is the size of the files being loaded. Translating the libraries to native code wouldn't necessarily make them smaller. Indeed, it would probably make them bigger.

        • Re: (Score:3, Interesting)

          by loubs001 (1126973)
          Yeah, I had a problem with that too. Because they added proprietary extensions that breached the specification (including Windows specific features), as well as omitting required features. Code written for the Microsoft VM wouldnt run on anyone elses. An implementation must be certified as compliant in order to use the Java brand. Microsoft's wasnt, so Sun sued. They won, and rightfully so.

          But I'm glad this happened. It caused Microsoft to go off and create rival platform (.NET) and a rival language (C#). M

  • Just starting out with Java (Score:4, Interesting)

    by RockHorn (896105) on Friday August 10 2007, @11:12AM (#20183989)
    I am a fledgling java developer, and so far I'm loving it! Every time I hear about the advances Sun is making towards GPLing java, the more I feel justified in taking the time to learn java.

    I came into this business from a bit of a back door (although I suspect it to be a common back door these days). I started with spaghetti code PHP, moved to OOP php with php4, then php5. I am now quite frustrated by the partial OOP implementation of php5, as I develop more complex applications. I become even more frustrated with PHP the more I learn about java. The type safety at compile time makes it far easier to develop bug-free code. Method overloading is problematic in php, I usually end up implementing a single function with all sorts of optional arguments, and checks to determine whether a particular parameter is an array.

    Additionally, Java gives me code re-use at it's ultimate. For instance, I write a single been that updates our LDAP; I then use that bean in a JSF web application, in a batch program running on an an IBM iSeries, in a command line application on Linux, and most recently in a Swing application. Having written the bean once when developing the first application, I never had to write a single LDAP query when developing my latter applications. Any bugs I find in the bean from one of the apps means the bug gets fixed for all the other apps.

    Not to mention that I do my development on my Mac, and deploy software across our organization to Windows and Linux desktops.

    Write once run anywhere for sure - I'm sold!

  • Sun can still do better ... and easily.

    "We've known that we weren't going to be able to satisfy everyone in the open-source and free software worlds. There are incompatible licenses and philosophies and approaches," Sands said. "We're trying very hard to figure out some way to bridge this, but we've not been able to do that."

    [...]

    The compatibility kit itself, though, is not an open-source project. "We wouldn't want people being creative about what compatibility means, because then you end up breaking

  • "Suck it, IBM"

    • Re: (Score:3, Interesting)

      by eln (21727) *
      Sun's test suite isn't just to verify your code works, it's to verify your implementation of Java complies with the standards before they allow you to slap the Java logo on it. It's a good way to keep things open while still maintaining control over the Java standard, and preventing fragmentation of the language.

      • Re: (Score:3, Informative)

        by Anonymous Coward
        Translation: No Microsoft MSJava++ with Sun's Java logo on it.

    • Re: (Score:2, Insightful)

      by Anonymous Coward
      Bullshit. Unit tests can at most prove that a single piece of software "works" in an internally consistent fashion. They might be marginally sufficient when you're building a single-platform doghouse-sized app. They're a very small part and hardly sufficient part of the process of building a skyscraper, though, and can't verify that an app will work in any specified environment.

      This Sun tool seems to validate your implementation against some standard.

      By validating your code against some reference standar
      • Wish I could mod the parent post up...
      • the issue is of letting Sun decide what is compatible or not. Let an outside body working from the published standards do that. And this Sun package is a set of unit tests. And as for cross-platform, of course well designed unit tests can check that.

    • Re: (Score:3, Insightful)

      by Marcus Green (34723)
      Go to your job web site of choice and key in the names of your favorite programming language. Notice that there are a huge number of jobs for Java skills (usually more than any other language but always a very close run match). Then ask yourself, if it is such a toy why are so many people prepared to pay good money to advertise for these skills?

      • Then ask yourself, if it is such a toy why are so many people prepared to pay good money to advertise for these skills?
        because they don't know any better? quality vs quantity? (see: Windows) I don't know. I'm just saying.

    • You failed programming, didn't you? (Score:4, Insightful)

      by Dancindan84 (1056246) on Friday August 10 2007, @11:05AM (#20183897)

      Java is a nice toy programming language, for those people who can't afford a 'real' compiler, Like Borland, or Even Microsoft. Hell, even GCC does a better job than most java interpreters.
      That's just golden.
        • Were you using the same version number on each computer? If you use a newer version to compile, say JDK 6, and then try to run it on an older version, say JRE 1.4.2, there can be incompatibilities. This happens because the JDK defaults to compiling towards the newest version (API and bytecode format), but you can configure options to compile to any old version level you want (target 1.3 which will work on 1.3, 1.4, 5.0, and 6.0 if you are going for serious compatibility). This can be a very useful featur
        • Right, and that's true in any language, isn't it?

          Hint: It's the programmer.
      • You fail it.

        That is, Compile it's own Compiler.

        Failure #1: Java's compiler is written in Java. The first use of the early Oak/Java VM was to get the compiler self-compiling.

        To Me, a Programming Language is 'Real' When it can fully bootstrap itself.

        Failure #2: Java *can* bootstrap itself just fine, thank you very much.

        http://www.jnode.org/ [jnode.org]
        http://jikesrvm.org/ [jikesrvm.org]

        "A distinguishing characteristic of Jikes RVM is that it is implemented in the Java(TM) programming language and is self-hosted i.e., its Java code runs on itself without requiring a second virtual machine."

        being an interpreted language, fails that test miserably.

        Failure #3: You called Java an interpreted language. Java is a compiled language that runs on a virtual machine. Like most VM-based platforms, that provides two options. The first is to interpret the bytecodes directly. The second is to compile the bytecodes into native code at runtime using a Just In Time Compiler. The most common JIT compiler for Java is the HotSpot VM [wikipedia.org]. HotSpot is quite capable of keeping pace with and even exceeding the performance of native code.

        http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html [idiom.com]

        I've once seen a student project, a java interpreter, written in Java.

        Failure #4: You see these things, yet you fail to take the time to understand them. You have failed as a geek. Turn in your member card immediately and leave in shame.
          • You continue to fail it. Amazing.

            Then explain why there's a "javac.exe" under Windows and [Linux]

            Simple. It's a stub. Typing "java -cp tools.jar com.sun.tools.javac.Main" all the time isn't very convenient, so Sun provides executables that load the JVM and execute the compiler. If you look in your JDK installation directory, you can find the tools.jar file in the "lib" subdirectory. You can try running it from that directory as above, or look inside the zip file for the mindblowing (eye roll) Java class files for the compiler.

            No, it can't. By definition you have to start with a JVM written in something that isn't Java. Otherwise your JVM is written in bytecode that nothing can run, since it isn't compiled to native code until runtime.

            Perfect example of someone who didn't read or take the time to understand. The Jalapeno VM and JNode OS are both written in pure Java. They used their own JIT compiler to compile themselves into native code. That native code is a Java program that runs on the native platform.

            By that definition, Python, Perl, and JavaScript are all compiled languages.

            Python is not compiled. Perl is not compiled. Javascript is not compiled. These languages are read in, line by line, and executed. You fail it.

            This is CS101 stuff we're talking about here. How badly can you fail it?

              • Re: (Score:3, Insightful)

                by AKAImBatman (238306)

                And how do you propose to run them and their JIT compiler without another VM?

                How you think Linus wrote the first version Linux? By flipping switches on the front of his Honeywell? Of course not, fool! He used Minix as a host platform to compile the first versions. You always need a host platform to bootstrap the first copy before it can become self-hosting.

                Modern interpreters compile the language and then run the bytecode. Early interpreters work the way you describe because memory was at a premium.

                These wo

                  • You mean like what Perl uses [perl.org]? :-/

                    Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run.

                    From my understanding of the engine, SpiderMonkey works along similar lines, using a combination of byte codes and parser information to perform execution. This is a bit different approach from the Flash VM, which pre-compiles the source into a representation executable by its "Actions" VM.

                    The difference between interpreted languages and compiled languages these days is largely academic.

                    I will agree with this. True interpreters are a rare find these days. Interpreting bytecodes is becoming a common method, and even JITs are showing up in a lot of interpreted languages. That being said, the one distinction is that interpreted languages rarely give up their interpreters. If you give them a dynamic piece of source code, they will execute it whether it does a strict interpretation of the source or a full compile to its internal VM.

                    In comparison, Java is a strictly compiled language designed for the Java VM platform. Furthermore, it is JITed at runtime and is no longer interpreted as most VMs designed for "interpreted languages" do.

                    Hell, even Java has JSPs, which use Java like a scripting language.

                    Scripting is not the same thing as interpreted. JSPs are compiled before execution. The file is turned inside out by the parser (all that HTML becomes output.write("") statements) then compiled by JavaC, loaded by the ClassLoader, and finally executed by the HotSpot VM. It's an involved process, but it's much faster than the traditional interpreted approach of PHP and pre-.NET ASP.
        • HotSpot on the server VM is not particularly "Just In Time" -- it compiles ahead of time. What's truly annoying though is that it doesn't cache the compiled at all, which partly accounts for its glacial startup time. Java runs circles around other bytecode-interpreted languages like perl and python, but the startup time is still tied as the #1 deal-breaker alongside the larged fixed heap that makes everything in Java look like bloatware even if it isn't.

          • Re: (Score:2, Informative)

            by matfud (464184)
            Actually hotspot compiles code after it has been interpreted for a while and it has noticed that it is a "hotspot" in the code (sort of there in the name really). The slow start up is because
            a) it loads and validates a fuck load of classes at startup (although the preverified core classes can be cached)
            b) it starts running in interpreted mode.

            matfud

    • Re:So what about gcj? (Score:5, Informative)

      by loubs001 (1126973) on Friday August 10 2007, @10:55AM (#20183767)
      Fortunately the GNU Classpath guys are right on board with OpenJDK. One of their most prominent members Dalibor Topic (who's the lead on the Kaffe VM) is on the OpenJDK governence board and works with Sun and other representivies on managing the project. Other promiment members like Roman Kennke, David Gilbert, Mario Torre and others. are active on the OpenJDK mailing lists and submitting patches. They are all interested in becoming regular contributors to the project.

      Other GNU Classpath developers working for Red Hat were very quick to produce a version of OpenJDK using pieces of Classpath to fill the wholes of "encumbered" components that havent been open sourced (like the font, graphics and sound engines that were licensed by Sun by 3rd parties). This is called IceTea. Though its more of a quick 'n dirty temporary project to have a completely GPL JDK right now until the holes can be plugged properly. For example, Sun released a more sophistated FreeType based font engine this week, and the rest of the holes will eventually be filled. But for now, IceTea is a great playground for experimentation. And as far as I can tell, Red Hat wants to contribute anything useful back in OpenJDK.

      You might that the GNU Classpath guys would be dissapointed, feeling that their hard work is obsolete, but no, they're happy because they know they were a big part of the reason why OpenJDK exists, and they're looking forward to contributing.

    • it's still being actively [gnu.org] developed. GCJ is part of GCC, so I don't think it will be abandoned anytime soon.
    • If you meant Classpath, the GNU-built JavaVM, it's probably going to see a sharp rise in compatibility with Sun Java.
      If you meant GCJ (GNU Compiler for Java), doesn't really mean too much. GCJ compiles Java into native code, which is entirely different from Classpath, Harmony, and SunJava
      • > If you meant Classpath, the GNU-built JavaVM, it's probably going to see a sharp rise in compatibility with Sun Java.

        Classpath is not a JVM, it is an implementation of the standard JDK library.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.