Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Java to be Open Sourced in October 267

thePowerOfGrayskull writes "Sun is now stating that the Hotspot JVM and javac will be open-sourced in October of this year, with the rest to follow by the end of 2007. There is still no word as to which license it will be released under. For those who haven't seen it yet, Sun has previously opened a public developer community site for soliciting feedback and providing updates about the process."
This discussion has been archived. No new comments can be posted.

Java to be Open Sourced in October

Comments Filter:
  • eh? (Score:3, Insightful)

    by slummy ( 887268 ) <shawnuthNO@SPAMgmail.com> on Tuesday August 15, 2006 @12:03PM (#15911179) Homepage
    "Source code for Java already is available and has been for 10 years", said James Gosling. I guess Open Source means they want free developers.
    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Tuesday August 15, 2006 @12:37PM (#15911417)
      Comment removed based on user account deletion
      • Re:eh? (Score:5, Interesting)

        by FST777 ( 913657 ) <frans-jan.van-steenbeek@net> on Tuesday August 15, 2006 @01:23PM (#15911829) Homepage
        In the long run, this will make Java more portable too. It took the FreeBSD Foundation some serious time lobbying before they could distribute Java as a package. Even from ports (source, for the non-BSDies here), Java is a pain on FreeBSD, because the lack of support, crazy patchwork and the need to download everything by hand, whilst signing agreements.

        I really hope that we can look forward to a working, recent Java version on FreeBSD without the old bugs and the trouble with OSS-principles in the near future. Kaffe / Classpath just isn't doing the trick. I wonder what this will do to OpenOffice.org.

        It all depends on the license. I do hope this will draw some of the fine folks at Kaffe / GNU / Apache who have done a great job by recoding Java to Java itself. But then, if it isn't the GPLv3, RMS will probably keep screaming for a "real free" reversed engineered version of Java.

        Well then, off to Flash... Adobe?
        • I know I'd switch back to FreeBSD in a heartbeat if this came to pass. I loved running FreeBSD. I just didn't enjoy the hassle of running Java on it.
  • by Anonymous Coward on Tuesday August 15, 2006 @12:05PM (#15911191)
    Java to be Open Sourced in October
    Hey, it's another October Revolutinon [wikipedia.org]!

    Long live the programmer-letariat!

    "While the Copyright exists, there can be no freedom. When there is freedom there will be no Copyright."
  • Big deal for OSS (Score:5, Insightful)

    by andrewman327 ( 635952 ) on Tuesday August 15, 2006 @12:05PM (#15911194) Homepage Journal
    Depending on the license that they choose, OSS purists can now utilize Java in their programs. OpenOffice.org ran into some issues [newsforge.com] when it began using Java to power some of its components. Hopefully the license under which this is released will be acceptable.
    • Re:Big deal for OSS (Score:4, Informative)

      by mrogers ( 85392 ) on Tuesday August 15, 2006 @12:44PM (#15911483)
      There are already free JVMs [kaffe.org] and free Java compilers [gnu.org]. The problem is the class libraries. Java's standard libraries are huge, and free reimplementations are having a hard time keeping up [classpath.org]. Without the libraries, open source versions of javac and the JVM won't bring us significantly closer to the goal of a completely free Java platform.
      • Re:Big deal for OSS (Score:3, Interesting)

        by _Swank ( 118097 )
        but the source or the java libraries IS available. i've been able to look at the source for the standard libraries for years (it's available with the Sun SDK). so am i missing something or are you complaining about the license the source is available under? if it's the second, why? why would java need to be under a more GPL like license? what are the real benefits?
        • Re:Big deal for OSS (Score:5, Interesting)

          by molarmass192 ( 608071 ) on Tuesday August 15, 2006 @01:41PM (#15911993) Homepage Journal
          You can LOOK at the source all you want, but why don't you make a change, say renaming the util package to utility, post your source code, and send Sun an email with a link to your modified source code. You'll be asked to remove your modified code lickity split. The SCSL is open source but NOT redistributable. So why a less restrictive license? Say I have a KDE based distro, I want to package Java with that distro, but there's a bug in java that breaks the clipboard under KDE but not GTK (this is a real life bug) and Sun refuses to address it because they only support GTK. Under the SCSL, you're toast. Under something less restrictive, you can patch the affected class, and distribute your "fixed" rt.jar.
  • by Anonymous Coward on Tuesday August 15, 2006 @12:12PM (#15911246)
    Is this "open source" as in "open source"?

    Is this "open source" as in Apple's "public source" Darwin project, where they're basically going "you can see and compile all the code, but no way are you going to be redistributing this as any kind of commercial project"?

    Is this "open source" as in Microsoft's "shared source" projects, where it's totally not open source at all except in a PR sense?

    Is this "open source" as in Sun's Solaris "open sourcing", where it's open source in all technical senses, but it's under an unbelievably elaborate license which exists for no reason except to engender GPL incompatibility and keep Linux from benefiting from the source release, which effectively scares everyone away from the project?

    Cuz really, unless "Java to be Open Sourced" really means "Java to be Open Sourced", it won't make a difference, acceptance of Java will continue to be held back by the perceived closedness of the Java language and real linux-unfriendliness of the Java runtime, and languages like C#/Mono will continue to make inroads until Apache finishes their Harmony project.
    • Is this "open source" as in Sun's Solaris "open sourcing", where it's open source in all technical senses, but it's under an unbelievably elaborate license which exists for no reason except to engender GPL incompatibility and keep Linux from benefiting from the source release, which effectively scares everyone away from the project?

      Care to explain this a bit?

      Sun Public License [opensource.org] is an official open-source license. What is "unbelievably elaborate" about it?

      And what did they do to 'purposely' endanger

    • "you can see and compile all the code, but no way are you going to be redistributing this as any kind of commercial project"

      From Sun:

      Sun also makes the JDK source code available for researchers and others interested in exploring the details of the JDK. Over the past several years, Sun has made the source code available via the Sun Community Source License (SCSL) terms. Sun continues to use SCSL for JDK 5.0. In addition, Sun is also releasing JDK 5.0 under the new Java Research License (JRL) which simpli

    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Tuesday August 15, 2006 @12:48PM (#15911523)
      Comment removed based on user account deletion
      • The GPL would be catastrophically inappropriate for Java, due to library linkage issues.

        If Java were GPL'd it would require that every single project that use it also be GPL'd.

        GPL'ing Java would kill virtually all commercial usage of it.

        LGPL'd, maybe....

      • Open Source means Open Source. There's a list of approved licenses. Sun are aware of this, they participate in the OSI, they've submitted licenses before for approval.


        These days, OSI does little more than rubber stamp any license that smells like a free one. They don't really do a very careful job of reviewing these things. As such, their involvement doesn't really tell you anything.
    • "Is this "open source" as in Microsoft's "shared source" projects, where it's totally not open source at all except in a PR sense?"

      Microsoft also has REAL open source licenses that are free as in free-issimo. [microsoft.com]
    • Is this "open source" as in Sun's Solaris "open sourcing", where it's open source in all technical senses, but it's under an unbelievably elaborate license which exists for no reason except to engender GPL incompatibility and keep Linux from benefiting from the source release, which effectively scares everyone away from the project?

      Its only been year since the release of OpenSolaris, and there are already many distributions [opensolaris.org] in development. So I don't think the CDDL is everyone away.

      While I don't care

  • Good (Score:3, Interesting)

    by Espectr0 ( 577637 ) on Tuesday August 15, 2006 @12:23PM (#15911318) Journal
    They better do it fast. Sadly for Java, .NET took almost everything good about Java and fixed lots of its quirks and gotchas. And with Mono, OSS people are giving it a chance too. With dynamic language support being heavily invested in both platforms, having outside contributors is critical.

    Now that Java can be redistributed legally (tell that to the slackware guy, he has always included it by default), and will be open sourced soon, it can fight back.
    • Re:Good (Score:5, Insightful)

      by cryfreedomlove ( 929828 ) on Tuesday August 15, 2006 @12:27PM (#15911353)
      Do you have any data that shows that Mono deployment in the enterprise is increasing, relative to java deployment? Because, in my experience of 8 years of enterprise java, Mono is not making any strides. It's a backwater that a few people are toiling in.
      • Oh, Mono deployment is big, that's for sure. The only trouble is that it's all on Windows, and they call it ".NET" instead.

      • Re:Good (Score:5, Informative)

        by THEbwana ( 42694 ) on Tuesday August 15, 2006 @03:01PM (#15912881)
        Mmm.. thats my take as well.
        My background is 9 years in Finance/IT in various technical (mostly programming / systems engineering) roles in three European countries, working in financial institutions of the size 30K-130K employees.
        The only .Net stuff I've seen is on the client side of some internally developed trading systems. The serverside, however, is usually run as J2EE apps running in one of the many servlet/ejb containers you see in the marketplace nowadays... J2EE simply rules the serverside and SWING apps are seen quite frequently. My guess is that banks will be happier extending eclipse when writing their client apps than going the .Net route...
        Maybe the .Net route is more popular within other market segments ? Anyone working in another industry care to comment ?
    • Do you have any like actual proof to back that up?
    • Unfortunately, .net is also pretty much married to M$ software on intel hardware. That setup won't be obsolete quite soon (on workstations), but clever people that run big hardware setups usually won't go for it. Which leaves java in a very interesting position; it will run both on the client and the server no matter what configuration. The difficulty for M$ will be to get .net onto the server, and I have a hard time believing that they can pull that off. Especially when java goes open source, so that e
  • October is the current projected release timeframe for JDK 1.6. I'm pretty sure that's not a co-incidence.

    Cheers,
    Ian

  • Sure, HotSpot may be a bit faster than free JVMs, but the free ones do function well enough. Also, free Java compilers are already readily available. For a long time, the main issue has been the maturity of free class libraries (particularly their Swing/AWT implementations), and now Sun says they'll be getting around to releasing that around the end of 2007. Almost smells like timing the release to a date when they think Classpath will have most of it nailed anyway.

    And then there's the license bit, but I sh
    • by kherr ( 602366 ) <kevin&puppethead,com> on Tuesday August 15, 2006 @12:38PM (#15911431) Homepage
      It's definitely the class libraries that make Java "java". The language is straightforward and there are decent JVM workalikes, but developers write their code around the class libraries. The problem I've always found with Java is the bloat of the class libraries, so I'd like to see open source distributions make lean and mean Java variants.

      A perfect Java distro would maybe drop all the deprecated methods (will Sun ever do that? Java 1.6 is a good opportunity...) and unbundle some of the least-used stuff like the CORBA and RMI stuff. Heck, even Swing and AWT should be optional packages. Why couldn't Java be structured sort of like a Java Web Start install, pulling in libraries only if needed. Almost everything is connected to the internet these days and good caching of libraries from trusted sources would be a decent way to get full functionality with a smaller initial footprint.

      • A perfect Java distro would maybe drop all the deprecated methods (will Sun ever do that? Java 1.6 is a good opportunity...)
        This question was asked again a JavaOne last summer and Gosling himself said they'll never remove deprecated items because of backward compatiblity.
      • A perfect Java distro would maybe drop all the deprecated methods (will Sun ever do that? Java 1.6 is a good opportunity...) and unbundle some of the least-used stuff like the CORBA and RMI stuff. Heck, even Swing and AWT should be optional packages.

        And the fragmentation begins...

      • Lean and mean Java implementations is all we need. "Works on Sun's, IBM's and XYZ's Java but not on gjc and others. And Kaffe needs some hacks and updates in order to make this app work". We are already seeing this kind of problems with .NET and Mono: you can either write simple apps that work in both, or advanced apps that work in Mono (and need GTK# in .NET Framework), or advanced apps in .NET Framework (and hope that it will work in Mono, although will look ugly on Linux and won't support Windows Native
      • by 955301 ( 209856 ) on Tuesday August 15, 2006 @02:20PM (#15912368) Journal
        Drop RMI? You realize that communication to EJB's is RMI right?

        And for the love of gods, why bother trimming the libraries? If you don't use the classes, they don't get loaded into the VM. Everything else is inflating including the OSes and you want to trim the programmers libraries?

        The more I look at your post, the more I realize you are straddling two fences. You say drop Swing and AWT implying that you are on the server in which case, your not downloading the JVM & libraries to the client anyway. Then you say Java needs to be like a Java Web Start install, meaning you are on the client side and therefore need the libraries you just said to toss! Oh and btw, Java Web Start is part of the jre download - if you have to download and install something to the client, why not download it all at once? Besides, the libraries *are* broken up - j2se and j2ee, correct?

      • I'm not sure how this "perfect" distro would be any different than a current distro other than disk space and lack of backward compatibility. Let's say you toss all of libraries you mentioned, it'll take up less disk space, but the runtime footprint itself probably won't actually change in any significant way.

        Much of java is loaded dynamically at runtime, so if you don't use something, it's not just sitting there, taking up memory. With modern memory management systems, any unused portion of memory is j

        • I was thinking of the install footprint, not the runtime. I guess I'm showing my (java) age. A huge barrier to adopting Java software in the client world is getting Java on the client. Really, Windows it the biggest pain in the ass because it doesn't come with Java. I don't care how big Java is on Mac OS X because it's just there. I guess follow-up comments lead me to realize that splitting up the libraries is pretty pointless in this broadband (tubes? dump trucks?) age.

          So I'll stand by my call to actually
      • A perfect Java distro ...

        Hehe, Sun just cringes when they hear "Java distro".
    • by Jason Earl ( 1894 ) on Tuesday August 15, 2006 @12:48PM (#15911524) Homepage Journal

      Exactly. Free Software has plenty of JVMs and compilers. Heck, the Free Software world has too many JVMs and compilers. What's needed are Java compatible class libraries under a license that is both amenable to proprietary and Free Software developers.

      At this point Sun is simply trying to draw support away from the various Free Java implementations. Sun knows that if the Free Software implementations ever become popular that its chances of controling Java long term are essentially flushed down the toilet. Sun reacted too late with Solaris, and it is desperate to keep Java from suffering a similar fate. So it is doing everything in its power to keep people away from Free Software Java-alike systems.

      If Sun were serious it would A) concentrate on releasing the Java class libraries, and B) it would have given Java developers some guidance on the license that it will be using. Everything else is just fluff.

  • I don't mean this as a troll at all. It's just the main thing that enamored me with Java 8 or 9 years ago was that I found myself getting projects done much faster in Java than in C++. Since then, however, I've found Python, which I'm even more productive in. For big projects, where strongly defined interfaces help control complexity, C# is now an option.

    So given that we have Python (for fast code) and C# (for big systems), do people really prefer Java for new projects anymore?
  • by Anonymous Coward on Tuesday August 15, 2006 @12:36PM (#15911410)
    If they had done this right 5 years ago, .NET would have been stillborn and Sun would be the worlds leading application platform vendor. That's a desirable and advantageous position for a hardware vendor to be in. Instead we're 2 months before a release and we still don't have enough details to consider java for future projects. With the benefit of hindsight, the best business decision Sun could have made back in 2001 would have been to relicense the java source code like they were being asked to.
    • If they had done this right 5 years ago, .NET would have been stillborn and Sun would be the worlds leading application platform vendor.

      There is a truth in what you are saying. The real problem with Java is the lack of pace, and the locked Java Community process, which locks the platform and language. Also, since Sun was keen to hold on to the Enterprise space, the platform became too focused on Enterprise applications, while the language was stagnating. It took C#, Python and Ruby to finally get some new
  • who cares? (Score:2, Insightful)

    by MobyDisk ( 75490 )
    Why are people clamoring for open java? As an application developer, I don't use Java, and it has nothing to do with it being open-sourced. It has to do with a bloated framework that I'm not supposed to distribute with my application, an inconsistent UI, and speed issues. If I could compile a native executable that Just Worked(tm) then I would love it.

    Java is still only good for simple embedded web applications, or server-side applications. From an application developer's stand point, Java grew out but
    • Re:who cares? (Score:5, Interesting)

      by 0xABADC0DA ( 867955 ) on Tuesday August 15, 2006 @01:38PM (#15911969)
      What is this "native executable" you speak of? To quote morpheus, "Do you think those are instructions you are running?" Pretty much every so-called native program you run is passed through the ld.so interpreter that relocates the binary and loads shared libraries. Grep the kernel sources for "ld.so".

      The only reason you have to ship a JVM with your app is because a) Microsoft intentionally sabotages compatibility (by strong-arming Dell, etc not to ship Java) and b) because Linux distros can't legally ship it because of license restrictions. Java apps work fine on a Mac without shipping their own JVM.

      With a JVM installed as a standard system component you run your Java programs just like any other program. You just double-click or ./ it.

      Mono has convenient language syntax with C#, but that's it. The CLR bytecode cannot be interpreted well, so hotspot like optimizations are far harder to do. It's a VM trying to be everything to everybody, so it's not really great at anything. It's startup time is far slower than a gcj'd Java program and it's throughput is much less than a hotspot'd one. The only real benefit is that it is oss.
      • because Linux distros can't legally ship it because of license restrictions. Java apps work fine on a Mac without shipping their own JVM.


        Thank you. That was the missing link for me. Why can't you ship Java with Linux? Is this a GPL thing? Or something Sun is doing? I don't think it matters if Sun open sources Java. But modifying their license so that people can actually get it on their systems might be a big improvement.
        • Hello Moby Disk,

          I have not talked with you since 1997 or so. Mini-Impulse hoo-boy!

          On topic, however, it seems you've missed the last 8 years or so of Java on Linux. The reason Java was generally not distributed as part of the various Linux distributions for so many years, is that Sun did not make it legally permissable for them to do so.

          There are some additional issues like Linux folks wanting to be able to provide security and bug fixes as appropriate for such a core component. The failure of Sun to make
  • Sweet! Next year! Damn.. that's close.
  • How long until some enterprising hacker adds all the features to Java that people miss, such as operator overloading? I personally would use Java far more if I could avoid code such as this:

    result = x.add(y.multiply(BigInteger.valueOf(7))).pow(3).ab s().setBit(27);

    (Example stolen frome Jamie Zawinski's "Java Sucks" rant.)
    Add operator overloading (and I mean PROPER operator overloading, not some find-and-replace garbage) to the JDK v6, and you've got a language that (despite being slower than C++ in som

    • result = x.add(y.multiply(BigInteger.valueOf(7))).pow(3).ab s().setBit(27);


      My goodness, what a perfect example of why NOT to use operator overloading.

      What would you use for an operator? The +, *, /, or what?

      How would operator overloading make the code more readable?

      And you could always wrap the whole thing inside one of x's methods, and give it a reasonable name.
      • Uh, "+" instead of ".add(" and "*" instead of ".multiply("

        result = (x + y * BigInteger.valueOf(7)).pow(3).abs().setBit(27) is arguably a lot cleaner: less to read, order of operation is implied by type (multiplication before addition).

        As someone who spends his day writing code in C++ that mostly multiplies matricies and vectors (occasionally transposing or inverting them) I still can't fathom why Java doesn't have operator overloading. It put C# a notch above Java for a second laguage to learn, for tha
    • Of course, that only really applies if you're using integers larger than 9223372036854775808 or smaller than -9223372036854775807, because you don't need BigInteger for anything in between those.
  • If Colonel Sanders would open-source those eleven herbs and spices, we could finally know with certainty how many of them are salt.
  • I doubt if this will change anything:

    1. In the application space, there are much more productive languages and tools. Think Ruby, Python. And extreme performance has never been a Java forte either.

    2. Core language capabilities are obsolete now. Bruce Eckel's famous piece The departure of the hyper-enthusiasts [artima.com] captures this nicely. And looking at the C# 3.0 spec, with lambdas, automatic type inference, monadic comprehensions and lots of functional programming goodness, Java is left way behind. MS is also way

    • "1. In the application space, there are much more productive languages and tools. Think Ruby, Python. And extreme performance has never been a Java forte either."

      Uhm, yeah. Let me guess, never programmed in Java, huh? Java on the server runs as fast, and occasionaly faster than native code. About 8 years ago, Swing was dirt slow, but even it has picked up since about 1.4.2 release. Don't even ge me going on the security superiority of VMs and compiled coded vs scripting languages like Ruby and Python. Clear
      • Don't even ge me going on the security superiority of VMs and compiled coded vs scripting languages like Ruby and Python. Clearly you do not have a clue...BTW, Ruby and PHP are just scripting languages. Get over it.

        Please define "scripting language". If you have the time, please categorize the following as "scripting languages" or "not scripting languages":
        1. Java
        2. Python
        3. Ruby
        4. C#
        5. Smalltalk
        6. Lisp
        7. Scheme
          • I have. I ask you the question because you refer to Python, for instance, as a scripting language but seem to indicate that Java is not.

            Python is byte-compiled and then run on a virtual machine (and I can, for instance, byte-compile to .pyc files, delete the source code or move only the .pyc files to another machine, and execute the .pyc files). The level of optimization depends on the particular Python implementation (CPython, Stackless, PyPy, and psyco all do it differently, with CPython doing only mi
            • Sorry, didn't notice that you weren't the poster I was originally responding to. The "you"s in the parent refer to JohnnyCannuk.
            • Inasmuch as I can parse your argument at all, you seem to be saying "Most scripting languages compile to bytecodes that are executed by a VM; therefore any language that executes bytecodes on a VM is a scripting language." If you would learn to express yourself more concisely, you could avoid fallacies like this.

              Perhaps it would help if you stopped taking the word "scripting" too literally. As you point out, languages like Perl no longer much resemble the scripting languages from whence they sprang. Nowad

  • This makes things more complicated for me.

    I'm a C++ Windows developer and I'm interested in starting to do some C# or Java. It is my belief that both are quite good and both can run on Windows and Linux (this is a requirement) so it doesn't matter which I choose technically. I feel equal hostility to MS and Sun so that doesn't matter. If the open source community decides on one or the other as being more 'free' and really gets behind it then I'll probably go with that.

    With Sun still playing games on open
  • I'm still not installing JRE to slow down my computer. It can be as open source as it wants. Why do people still bother with java? It's a poorly designed, poorly implemented language. I'm not going to bog down my machines with any program that slows it down un-necessarily, which means: I'm not using anything written in java. Now if it being open sourced means that I can get applications written in java as precompiled binaries not needing JRE, well, then maybe.

    rhY
    • ARG. Are you on some kind of medicine that makes you slow? Java is just as fast as any other language once you consider the quality of programming. A perfect C program is faster than a perfect Java program at the same task. Of course, a real world C program is never perfect, so you are VERY likely to see Java software which has better performance than natively compiled software.

      Of course, how would you know? You're somehow morally opposed to software that runs 30% slower than some hypothetical ideal.
  • drop dead, Sun (Score:3, Insightful)

    by m874t232 ( 973431 ) on Tuesday August 15, 2006 @03:20PM (#15913202)
    10 years ago, Sun promised ANSI and ISO standards for Java plus open source implementations. What did we get? No standards, a lot of FUD (yes, FUD from Sun) about how they can't because of MSFT, proprietary and closed implementations, costly compatibility tests, bloated APIs and implementations, and threats of lawsuits.

    Now that FOSS implementations are mature and nearly complete, Sun is trying to undermine them by finally open sourcing Java (at least in name--in practice, the license will probably be a sham).

    The sooner Sun goes out of business, the better for everybody. Microsoft at least makes no secret about where they stand on FOSS, but Sun pretends to be a friend to FOSS but keeps spreading FUD about FOSS and keeps stabbing FOSS efforts in the back.
  • by kmahan ( 80459 ) on Tuesday August 15, 2006 @03:47PM (#15913584)
    To me the real question is "When will Sun be releasing the various TCKs?" The conformance suites are what is needed to validate any of the java implementations and call them "Java" in the eyes of Sun (and their lawyers).

    As James Gosling has said -- the source to the JVMs and libraries has been available for 10 years. But the TCKs aren't available in source or binary form.
  • It's interesting to note that "open source" is now a verb. And we can be sure of that because the poster has inflected it for tense.

    The part of the compound that seems most verbal to me is "open" -- yet they don't refer to it as "opened source" -- which ostensibly refers to source (code) which has undergone an event of opening. Instead, the whole kit and kaboodle has been verbalized. Or, alternatively, "source" is being inflected as a verb on its own, becoming past tense "sourced", leaving "open" as ...
  • by Big Jojo ( 50231 ) on Tuesday August 15, 2006 @09:08PM (#15916094)

    There are a lot of embedded CPUs that have "Java Acceleration" built in. I'm specifically concerned with ARM's Jazelle -- as found in ARM926ejs CPUs like the one in the Nokia 770, for example, and all ARM v6 CPUs -- but there is also Atmel's new AVR32 (Linux port is in the MM tree) and there are a few other processors that do the same thing.

    But you can't get specs on how to use that stuff ... and if you ask the chip vendors, the answer is that it's Sun's fault. To get specs, you must sign agreements with Sun. That's for basic stuff like how to preserve the relevant processor context, and how to enter or exit the "execute Java bytecodes" CPU mode, and of course exactly what bytecodes exist. (They just accelerate the bytecodes ... some things need to punt to runtime code.)

    What that means is that for example GCC can't use that CPU acceleration by having its Java runtime (GCJ/GIJ) build on it ... one assumes that this means a performance penalty for at least the bytecode interpretation parts of almost every Java runtime environment, though of course it would be interesting seeing how things like HotSpot affect the performance numbers. (The CPUs that have Java bytecode acceleration are by the way not ones that normally have big CPU caches, high clock rates, or very much memory to waste on the stuff HotSpot does.)

    So my question: Is this "Open Sourced Java" going to cover ARM's Jazelle? And the AVR32 Java acceleration? And other chips?

    Or is it going to be the same-old, same-old? Folk working with embedded systems want to know... the big system bloatware that that Sun ships is not especially useful. Finally loosening the reins on the bytecode acceleration hardware would be a much more useful step.

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...