Slashdot Mirror


Simon Phipps on the Process of Opening Java

twofish writes "Simon Phipps, the chief open-source officer at Sun Microsystems, has reaffirmed Sun's commitment to Open Source in an interview with computerworld. The focus of the interview is Simon's efforts to fully open source Java. He points out that many problems need to be resolved before Java can be open sourced — ownership, legal, access, encumbrances and relationships with Java licensees. It took Sun a full five years to solve these issues with Solaris. However Simon predicts that it won't take anything near this amount of time to complete the task with Java. Of course, one of the other concerns for OS Java is the resulting incompatible versions and breaking of the Java WORA model (Gosling himself has always been particularly concerned about incompatible forks resulting in the introduction of an open source version of Java) and this opens up additional problems for the open source Java model."

12 of 152 comments (clear)

  1. Incompatible Java forks by Anonymous Coward · · Score: 5, Insightful
    Gosling himself has always been particularly concerned about incompatible forks resulting in the introduction of an open source version of Java)
    So hold onto the trademark, the same way the Mozilla foundation do, and only let implementations that pass a rigorous testsuite use it.
  2. Quit the talking by Alphager · · Score: 4, Interesting

    or at least talk about some facts. All we hear from Sun is blabla about how they will open-source parts of Java in one or two years. What i want to know: -Which parts of Java? -WHICH LICENSE ?

  3. Other Open Source languages don't seem to suffer by Burdell · · Score: 4, Insightful

    There are many open source programming languages already (perl, python,
    etc.), and they don't seem to have a problem with forking or
    compatibility.

    If Sun fosters a good development community, there shouldn't be a
    problem.

  4. Re:Java already breaks the WORA model by 99BottlesOfBeerInMyF · · Score: 5, Insightful

    Usually this is because they have some old version of Microsoft's Java Runtime installed, which only supports Java 1.1 (badly). What a mess! I can't really see how opening it up will make it any worse than it already is today.

    Okay so MS broke the law and released an intentionally broken JVM to try and kill Java as a dev platform. The courts stopped them, but you're still dealing with the mess with a few remaining legacy systems from that time. You don't see how giving MS an opportunity to bundle a new broken version on every computer sold in the world could make things worse?

  5. Exactly by sterno · · Score: 5, Insightful

    It is fair to say that down the line even when they do opensource it, Sun's version will be the defacto standard. Figure if they and IBM work together on new versions, there's a pretty good guarantee that there won't be any major forks. Sure, there will be forks, but invariably those forks won't be what the average corporate server is running on, etc. Since it's open source, any of the good changes from those forks can be rolled back into the main Sun standard.

    I can understand Sun's fear as Java has been a huge part of their business, but I think as long as they keep pushing the standard forward forks will be irrelevant.

    --
    This sig has been temporarily disconnected or is no longer in service
  6. Solaris - solved? by kripkenstein · · Score: 4, Insightful

    It took Sun a full five years to solve these issues with Solaris.

    Solved? We should be so lucky. Things are far from solved. If Sun had released Solaris under the GPL, that would be good and done. Instead, it's under their own CDDL, which isn't easily compatible with the far-more-common GPL. This leads to issues for interesting projects like GNU/Solaris (Nexenta), which should have been quickly welcomed by the Open Source community. Instead, Sun's choice of the CDDL makes things complicated where they shouldn't be.

    So, in short, I would not say that Sun 'solved' these 'problems' with Solaris, and I sincerely hope they do a better job with Java.

  7. That's a popular method. by jd · · Score: 4, Insightful
    • The "red book" that defined the CD standard was the main reason CDs were as interchangable as they were. DVDs, which have no such rigorous standard to meet, tend to be less predictable.
    • IPv6 hasn't got an "official" centrally-run test suite, but such suites for the purpose of certification do exist.
    • C follows standards, rather than official regression tests, so you do get a lot more variation in quality and interchangability. In general, though, it demonstrates that simply defining a central standard is adequate for basic stuff.
    • POSIX used a mix of standards and official testing, and had a big impact on the interoperability of Unix systems - though nowhere near as much as seems to have been hoped.
    • Standards and tests by committee seem to be a Very Bad Idea. CORBA and SQL followed this road and have resulted in guaranteed inefficiency - apparently for the purpose of promoting the "extended" packages released by the vendors who created the standards in the first place.


    If the process is followed - hey, that's great, but is needs to be done right if it is to be worth the doing.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  8. Re:Someone has to say it by grammar+fascist · · Score: 5, Informative
    Java sucks *and* it's closed source. I'll stick to C, Python and Perl thank you.

    Naw. Here's the real deal, from someone who knows quite a few languages:

    - Java is adequate for just about every programming task
    - Java's generics are mostly adequate
    - Java's GUI support is good once you let Swing twist your head into a fleshy knot
    - Java's library support is above average
    - Java's floating-point performance is quite good, especially with HotSpot
    - The HotSpot runtime is freakin' amazing at what it does
    - The Java language is wordy, which mostly has to do with strict typing (and lately, from adding generics)
    - Server-side Java (JSPs, servlets, etc.) is unnecessarily complicated and probably designed by Satan himself

    Hope that helps.
    --
    I got my Linux laptop at System76.
  9. Re:As a web app developer... by Reverend528 · · Score: 4, Funny

    AJAX and DHTML are terrible for writing web servers. That's why I write all of my web applications in javascript and XUL. It takes only a small amount of rdf to turn firefox into a full-featured web server, and the pages it serves are pretty much guaranteed to look good in any gecko-based browser. Though, every once and a while the server experiences problems when someone ignores the post-it-note on the monitor and starts using the it to read slashdot.

  10. Re:Java already breaks the WORA model by jilles · · Score: 4, Interesting

    I don't know about your definition of interesting but most of the java stuff I work with on a daily basis works unmodified on the three big desktop platforms (and probably everything else that runs java 1.5) and does so for the ten or so years I've been developing Java. This stuff combined is probably several million lines of code. Also all of the stuff I write in Java is 100% crossplatform, barring the odd jdk bug that somehow fell through the 60000 or so unit tests they unleash on the jdk nowadays (just a disclaimer, can't recall ever encountering one). In my previous company we developed on windows, had staging servers running linux and deployed more or less blindly to our customer sites running windows 2000, 2003, various flavours of linux and even some sun machines. Worked every time. Portability was never an issue. Not even having to test for portability issues is a huge time and cost saver.

    A good example of a portable J2ME app is opera mini which exists in only two variants the both of which work across pretty much all java capable phones except maybe for the really crappy ones, such as your Palm based one (blame Palm, not Sun). J2ME is a modular specification which unfortunately leads to the interesting situation that the more of the modules your app uses the less portable it becomes. Pretty much all of the modules are optional and with MIDP 1.0 many vendors added loads of vendor specific APIs as well. Many applications written for that mixed bag of standard and non standard extensions are not portable.

    MIDP 2.0 mostly removes the need for vendor specific APIs (though many vendors still ship them). Upcoming MIDP 3.0 is even better apparently. of course many games need to make assumptions about device specifics (e.g. screen size, number of colours, keyboard layout) which unfortunately leads to many portability issues. These problems are hard to solve and currently J2ME seems the best solution the market has come up with. Most device specific binaries of J2ME apps merely include some minor modifications, optimizations and packaging. I agree that testing for all that is a major PITA for developers. If you have a better solution that works for non trivial applications across the thousands of different brands and types of mobile phones, get some venture capital and get rich!

    --

    Jilles
  11. Re:Java already breaks the WORA model by Decaff · · Score: 4, Insightful

    I have a Java client on my webserver and half the mails I get are because the Java client doesn't work on people's computer. Usually this is because they have some old version of Microsoft's Java Runtime installed, which only supports Java 1.1 (badly).

    What a mess! I can't really see how opening it up will make it any worse than it already is today.


    Guess what! I have some Linux software that won't run on the 1.0.x kernel or with really early versions of libc. By the same reasoning this must surely mean that Linux is broken and you can't write the same code for different platforms.

    Of course this is nonsense, and isn't what WORA is about, and certainly shouldn't have been rated 'insightful'. WORA does not include some kind of time machine facility to allow software written to current VM and language and library specifications to work on 10-year old VMs and old libraries. The idea is, of course, that if you write for Java 1.4.2, your software will run on any Java 1.4.2 VM (or later) on any platform.

  12. Re:Java already breaks the WORA model by Tim+C · · Score: 4, Informative

    Another good hint is when developers have to "port" their application from their own desktop to work properly on the test server.

    In 6 or so years of doing server-side Java development, I have never needed to do that, nor have I ever heard of anyone needing to do so. I humbly suggest that if someone does find themselves needing to do so, they've done something very wrong.