Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Java Programming

On the Horizon: an Apache-License Version of Java 268

Posted by timothy from the better-definition-of-trusted-computing dept.
mparaz writes "Geir Magnusson of the Apache Software Foundation announced a J2SE 5 implementation project called 'Harmony.' It covers the virtual machine and the class libraries, and aims to pass the Sun specification. A FAQ is available."
This discussion has been archived. No new comments can be posted.

On the Horizon: an Apache-License Version of Java More

On the Horizon: an Apache-License Version of Java

Comments Filter:

  • great news (Score:5, Insightful)

    by Sv-Manowar ( 772313 ) on Saturday May 07, 2005 @09:33AM (#12461713) Homepage Journal
    Could this be an essential aid to Tomcat and the increasing number of projects the apache foundation are managing within the Java space, such as ANT. This can only be a good thing

    • Re:great news (Score:5, Informative)

      by timeOday ( 582209 ) on Saturday May 07, 2005 @10:01AM (#12461858)
      If it ever happens, yes... but so far it's just a message on a bulletin board. Implementing the JVM itself is no trivial task, and would take years to reach the performance and stability of Sun's JVM even with huge resources. They have chosen their own unique architecture so I don't think code reuse is in their plan.

      Then there are the class libraries, which have sprawled to a massive scale, and in comparison make implementing the JVM look easy. Look at Wine [winehq.org], which still isn't an alternative for Win32 (only selected applications are supported), after years and years of work. Or Mono, which cannot and probably never will run arbitrary .Net apps.

      • If it ever happens, yes... but so far it's just a message on a bulletin board. Implementing the JVM itself is no trivial task,

        it is indeed far from trivial, tho it does not need to be as complex as SUN made it.

        and would take years to reach the performance and stability of Sun's JVM even with huge resources.

        There are 2 issues here:

        • You don't have to achieve that level of 'quality' on the short term, it has to be 'good enough'. There are many examles where 'good enough' software is extremely succesfu

      • Re:great news (Score:2, Informative)

        by genneth ( 649285 )
        Actually a JVM is trivial -- it's the class libraries that are difficult. On the JVM front there is Kaffe, Jikes (the JVM bit, not just the javac bit), ikvm, etc. That's just the ones I can remember how to spell. Class libraries however is pretty much restricted to the Sun one and the GNU (attempt at) one.

        • Re:great news (Score:5, Informative)

          by wfmcwalter ( 124904 ) on Saturday May 07, 2005 @01:55PM (#12462988) Homepage
          Well, an elementary JVM is trivial, but a half-decent one has some harder stuff. Assuming they'll want to get Harmony up to the standard of Apache-httpd and Apache-tomcat, the JVM component will be a big job too.

          The bytecode loop and elementary classloader are indeed straightforward (which is why there are so many of them hanging around), and doesn't really get harder between a barely-working JVM and a decent one. Lots of other stuff, however, does:

          • A dumb, blocking, non-generational mark-and-sweep garbage collector is fairly straightforward (handling blocking and native methods wrt GC is a complication, if a manageable one). But for a box serving lots of connections on a busy website, you don't really want half second long pauses while the GC sweeps the whole memory. You really need a generational collector, and you really want one that's either non-blocking (yes, that's hard) or resumable. The nice thing is that the GC is fairly self contained (not entirely, as it interworks with synchronisation and the native method interface) and there are lots of university research groups who have done lots of research on GCs (for java and other languages) so it should be possible either to pick up some research collector or farm the work out to some eager masters students.
          • Efficient management of native synchronisation resources has an important effect on scalability. Mature JVMs go to great lengths to marshall the number of native synchronisation primitives the JVM instance uses (e.g. with some kind of mutex pool, assigning an OS mutex to a java one only when it is in scope). They can work without this for a while, but it needs done eventually. I see Doug Lea is onboard, and this kind of stuff is Doug's meat-and-drink.
          • The verifier is hard to get right. Sun's one is the product of careful design and then of several analyses by third parties. For example, one univerity wrote a verifier from the JVM spec in a formal language (Z or something) and then threw millions of randomly generated program fragments at their one and the Sun one. Where the two differed, the group analysed the program in depth. From this they found dozens of cases where the two verifiers differed materially; most were due to different interpretations of the JVM spec (which, one hopes, resulted in the language of the spec being tightened) but about ten were nontrivial holes in the Sun verifier. Last time I was involved with this (a few years ago) Sun insisted that all Java licencees (even those who had written their own JVM etc. entirely from scratch) run the Sun verifier. Luckily, the verifier is like the GC - it's a subject of ongoing academic research, so there are universities who might be persuaded to do the heavy lifting. And for a trusted enterprise setup you can do without the verifier anyway (it's really only needed for untrusted mobile code like applets or JINI things).
          • But the really big task is dynamic compilation. A bytecode-interpreted system isn't credible for any real application. A JIT will do, at the expense of sluggish performance and drastic memory-munching. A real hotspot-like smart, self-monitoring dynamic compiler is really necessary for a quality JVM. I guess the Harmony folks will spend a lot of effort here, as it's a lot of work and its too tightly bound to your JVM internals to either farm out or to allow you to easily take something off the shelf.
          Still, I hope I've not sounded too negative. It's all doable (python and mono do most of this stuff between them, neither with a vast team) and the lack of a free or open JVM has been an uncomfortable gap between LAMP and tomcat for too long.

          Heck, maybe it's just a strategy to get Sun to open Tiger sooner rather than later.

          • Re:great news (Score:3, Interesting)

            by AstroByte ( 718093 )
            Most of your points are right, however, I take issue with the statement that the bytecode loop is trivial. This, I'm afraid, is a widely held misconception :)

            While a simple switch-based interpreter is trivial to implement, it will perform abysmally on modern processors because of the overhead of the computed jumps. Writing an efficient interpreter has been an active research area in itself (see http://www.complang.tuwien.ac.at/projects/interpre ters.html [tuwien.ac.at] for some good papers). In fact, the difference

      • Re:great news (Score:3, Interesting)

        by steve_l ( 109732 )
        1. The Apache Portable Runtime will probably be the basis for a lot of the portabliity stuff.

        2. OSS things -like eclipse's SWT windowing toolkit wont need rewriting -they become the test suite as well as part of the distributable.

        3. Things like garbage collection and VM performance could be an area for research. Hopefully it will be a good platform for academic research, stuff we can use.

        4. Testing is the big problem. There are not yet enough public tests to verify JVM 'compliance'. I dont know if apache

      • As for the JVM, do note that the list of people involved includes at least half a dozen with "commercial JVM experience."

        If they come up with a JVM that can implement the core of Java, the existing Java class libraries would presumably not have to be entirely rewritten immediately but would run on the compatible JVM. The class libraries could then be rewritten over time.

        Obviously somebody thinks that Sun is not going to open source Java anytime soon and has decided to up the ante. Given the amount of proj

      • Re:great news (Score:4, Insightful)

        by afabbro ( 33948 ) on Saturday May 07, 2005 @01:21PM (#12462811) Homepage
        Flash back to 1993...

        Will anyone ever reimplement the Unix kernel? So far it's just a message on USENET. Implementing the Unix kernel itself is no trivial task and it would take years years to reach the performance and stability of Sun's kernel even with huge resources. They have chosen their own unique architecture so I don't think code reuse is in their plan.

        Then there is /usr/lib, which has sprawled to a massive scale...

  • Better for the Linux User (Score:5, Insightful)

    by MoogMan ( 442253 ) on Saturday May 07, 2005 @09:34AM (#12461718)
    Cool! This will be useful for the majority of Linux desktops, because it means it could be installed as part of a default install, rather than having to download it and install it afterwards (==hell for lots of users).
    • Don't you think a reimplementation of the VM is too much of a price to pay for such a small convenience?
      • reimplementing stuff that people need but that isn't availible as free software is what made it possible to have a completely free software os.

        sun has imo played a very sneaky trick by making java not truely free software but just free/open enough to keep the demand for a clone at a fairly low level.

        • Re:Better for the Linux User (Score:4, Insightful)

          by IamTheRealMike ( 537420 ) on Saturday May 07, 2005 @10:27AM (#12461971)
          The real question that's on most peoples lips and conspicuously not answered in the FAQ is what is wrong with the GNU implementation. They mention that Classpath and GCJ already exist but fail to mention why these are not open source enough. Red Hat is putting a lot of effort into Free Java - why does Apache feel the need to compete with this?

        • Re:Better for the Linux User (Score:5, Insightful)

          by beforewisdom ( 729725 ) on Saturday May 07, 2005 @11:47AM (#12462333)
          "sneaky" ?

          I really hate to defend Sun,...really, I do, but they are the ones who spent a ton of money and work developing Java.

          They make it available for free of charge.

          what jerks
          • yes i said sneaky i didn't say right or wrong i just said sneaky

            lots of projects are now basing on java and if/when sun (or in the worst case whoever buys it from thier liquidators) start tightning the screws there could be some real pain.

            imo java could really do with a free (as in stallman or freer) implementation that actually works properly. BUT much of the drive to create one is removed by the fact that java and its source are a free (as in beer) download.

    • Re:Better for the Linux User (Score:5, Interesting)

      by DrXym ( 126579 ) on Saturday May 07, 2005 @11:06AM (#12462149)
      The same could be said for Kaffe, gcj, classpath et al. And in fact it probably has been, each in their time being heralded as a way to break from Sun.


      Sadly the reality is that no Java is even remotely as reliable or complete as Sun's implementation for the desktop let alone anywhere else. Major work had to be done to gcj just to make Open Office 2.0 run, which hardly speaks for its maturity. And other impls such as Kaffe are missing critical security functionality such as byte code verification. And enterprise level functionality? Forget it.


      Personally I'd love to see a free and open source Java, but its taken years to get this far and its still not there yet.


      • So? The world isn't going anywhere (just yet). If it takes another ten years to get a free Java, what's the harm?

        It took over ten years for Linux to be truly useful to people. Should the Linux hackers all have stopped because of that?

        • The harm is that Java, which is a massively powerful and useful environment doesn't ship with any non-commercial version of Linux. Yes, you can download it, but no dist except JDS can't use or rely upon it in any way because it is an optional component. Ruby, Python, Perl etc. have their place but they're nowhere near as powerful as Java either in the breadth of applications or speed even.

          Furthermore, the absence of an open source and reliable Java introduces a pile of uncertainty to anyone developing J2E

      • Well, in the first place, most C coders aren't interested in Java...the projects are worked on only by a subset of the group that is.

        In the second place, gcj is a complete enough Java to compile OpenOffice.org 1.1 (Red Hat build thier distributables that way). The problem is the closed source libraries which Sun has been guaranteeing are a moving target. And only distributable by Sun.

        Personally, I hope Harmony is successful, but gcj is what I expect to be using (though I *do* have Kaffe installed, and on
    • No insult to you MoogMan, but my reaction is always "WTF?" when gnu/linux people mention downloading and setting up Java as a problem.

      These are often the same people who download entire operating systems and install them by compiling untarred coded.

      I find setting up Java to be one of the more straight forward tasks to do when I set up a new gnu/linux box.

      I think the gnu/linux people have complaints to make, but I don't think it is about ease of setup issues with Java
      • my reaction is always "WTF?" when gnu/linux people mention downloading and setting up Java as a problem.

        These are often the same people who download entire operating systems and install them by compiling untarred coded.

        I can't speak for the GP or any of the "same people", this is just my own take on it...

        Sure, I've installed software from a tarball. Would I ever do it if I could get the software through a package manager? Hell no.

        The hassle of installing Java on Linux might be minor compared to some of

  • Kaffe, Classpath... (Score:4, Informative)

    by otisg ( 92803 ) on Saturday May 07, 2005 @09:36AM (#12461728) Homepage Journal
    For those too lazy to click through to that blog entry, Kaffe, Classpath and other solutions already exist, and this is not the first.... although coming from Apache carries some weight.

    • Re:Kaffe, Classpath... (Score:5, Informative)

      by Fefe ( 6964 ) on Saturday May 07, 2005 @10:23AM (#12461946) Homepage
      Had you bothered to read the blog entry yourself before commenting, you would have noticed that Kaffe and Classpath members are part of this project.

      This does appear to be a consolidation project. We have several contenders for Open Source JVMs under Linux, but most of them lack in some way or the other compared to the Sun and IBM JVMs. So having one up-to-date one instead of five not-quite-there-yet ones is a step forward.

      • Re:Kaffe, Classpath... (Score:3, Informative)

        by Anonymous Coward
        Some Classpath members may be part of this project - but the Classpath code ain't . This is due to the incompatible license. Writing all that java class library code took years. It will be interesting to see whether the Classpath code will simply be lifted (wink, wink) or rewritten from scratch. It's a huge task. The VM, by comparison, is a dime a dozen. Any moderated motivately hobbyist can knock off one in a few months. It may not run quickly, but it will run. The java class libraries' quality and complet

  • basic architectural blueprint (Score:4, Insightful)

    by anandpur ( 303114 ) on Saturday May 07, 2005 @09:37AM (#12461732)

    http://people.apache.org/~geirm/harmony.jpg [apache.org]

  • reminds me of QT (Score:3, Informative)

    by moz25 ( 262020 ) on Saturday May 07, 2005 @09:38AM (#12461734) Homepage
    I remember a project called Harmony that had the purpose of being an API-compatible clone of QT but without the license issues: www.kde.org/whatiskde/qt.php [kde.org]. It never got off the ground though.

  • Excellent! (Score:4, Funny)

    by multipartmixed ( 163409 ) on Saturday May 07, 2005 @10:01AM (#12461854) Homepage
    And after it passes the Sun spec, we can fix it to be useful (since we have the source) with a simple header change:

    #define sleep(a) while(0) ..that should eliminate half of the code, decreasing binary size and actually performing. ;)

  • JamVM (Score:5, Interesting)

    by Hugo Graffiti ( 95829 ) on Saturday May 07, 2005 @10:22AM (#12461936)
    I hope they choose JamVM [sourceforge.net] for the VM. It's a fairly new VM but impressively lean and mean (100k executable that still supports the full spec). From the JamVM web site, here is a list of the main features:

    • Uses native threading (posix threads). Full thread implementation including Thread.interrupt()
    • Object references are direct pointers (i.e. no handles)
    • Supports class loaders
    • Efficient thin locks for fast locking in uncontended cases (the majority of locking) without using spin-locking
    • Two word object header to minimise heap overhead (lock word and class pointer)
    • Execution engine supports basic switched interpreter and threaded interpreter, to minimise dispatch overhead (requires gcc value labels)
    • Stop-the-world mark and sweep garbage collector
    • Thread suspension uses signals to reduce suspend latency and improve performance (no suspension checks during normal execution)
    • Full object finalisation support within the garbage collector (with finaliser thread)
    • Garbage collector can run synchronously or asynchronously within its own thread
    • String constants within class files are stored in hash table to minimise class data overhead (string constants shared between all classes)
    • Supports JNI and dynamic loading for use with standard libraries
    • Uses its own lightweight native interface for internal native methods without overhead of JNI
    • JamVM is written in C, with a small amount of platform dependent assembler, and is easily portable to other architectures.

  • binary compatibility? (Score:3, Interesting)

    by palinurus ( 111359 ) on Saturday May 07, 2005 @10:26AM (#12461962)
    I bet they can pull off a really nice VM. The existence of multiple VM implementations has yet to produce the kind of community fragmentation that a lot of people have prophesized, is a credit to the strength of sun's spec writing, and has been good for the platform overall (my java apps, both client and server, run without modification on os x...) I wonder about the class libraries, though.

    It seems like maintaining binary compatibility between serialized classes (esp. for collections and java.lang classes) is essential, at least if you want to do J2EE stuff in the long run. It will be at least a nuisance to, say, reimplement java.util.HashMap in a binary-compatible way without illegally appropriating Sun's IP (something the project seems pretty conscious of in their charter/FAQ).

    It's not impossible, but I think the IP challenge there is the real issue (not to mention the fact that your implementation is going to be constrained to being nearly identical to Sun's, at least in terms of overall strategy, if not line-by-line). If you read Sun's code in one window, and then write the same member variables in the same order in another window, is that copying code or not? And even if you do write something completely different (say, going with the HashMap example), you have to come up with some kind of transformation from your choice of state variables to sun's serialized state variables, which could look pretty nasty.

    I also pity the poor bastard that has to write those AWT libraries...

    • I also pity the poor bastard that has to write those AWT libraries...
      Being Apache, question is if they will not concentrate on typical serverside libraries, and drop GUI java.
    • It will be at least a nuisance to, say, reimplement java.util.HashMap in a binary-compatible way without illegally appropriating Sun's IP

      Why do you say that? The serialized format is documented fully:

      Serial Data:
      The capacity of the HashMap (the length of the bucket array) is emitted (int), followed by the size of the HashMap (the number of key-value mappings), followed by the key (Object) and value (Object) for each key-value mapping represented by the HashMap The key-value mappings are emitted in
      • Any schmuck can make a HashMap, but getting it so that you can take a HashMap from your VM, serialize it, send it to another VM, and then it read it without the values changing around is nontrivial unless you can use the same source code as the other person. As far as the open documentation we've got says, it magically creates a hash value for every object, and every object is magically turned into a serialized form, with the JVM turning them back just as magically. "It just happens." is not really helpfu
    • It seems like maintaining binary compatibility between serialized classes (esp. for collections and java.lang classes) is essential

      I was under the impression that serialized objects were never meant to be portable between different JVMs?

  • Mono Mono Mono (Score:2, Insightful)

    by synthespian ( 563437 )
    Quit the Java dependency. Head towards open standards.

    How long will it take for the open source community to understand that C# is not only "a Java replacement", but a better technology? How long till people start reading the docs behind C#'s design?

    Let's get this clear: Mono is free software, Java is not!

    My intent is not to troll, but simply point out that, in the long run IMHO we should stick to Mono. Sun had its chance. It's done too little, too late.

    Why all this investment of time on something that
    • As somebody who's recently done some C# / .NET programming, I can see where you're coming from. But I'm afraid the platform has a long way to go before it becomes as useful to the open source community as Java. When there is a well accepted platform-independent GUI for it (I've seen GTK#, which is getting there, but the number of projects using it so far seems to be fairly small), when its APIs reach the same level of functionality in areas like 3D graphics, telephony, e-mail manipulation and cryptography
    • It will take some time for Mono to catch up to Java. But so far, everything I've seen is impressive. Having recently read the C# language specification, I found that I really liked it much more than the Java programming language. I also loved that the VM is designed for non-Java languages, including tail-recursion.

      Whoever is second in designing a copy of someone else's work is always able to fix lots of little mistakes in the copied work.

      There are a few things that, IMHO, are important for Mono.

    • While I agree that having many Java projects ported to Mono might be a good thing, I see the same problem with Mono as with Java - the primary implementor is a corporation - and unlike Sun, this one has a major problem with ANY kind of competitor.

      We have yet to see whether Miquel can keep Mono going in the face of a Microsoft lawsuit.

      In my view, both this project and Mono are good ideas and should be pursued (along with Perl and the other scripting languages) - and it would be nice if someone came up with

    • Re:Mono Mono Mono (Score:3, Insightful)

      by HiThere ( 15173 ) *
      In 17 years I'll trust the current Mono implementation to be free from MS traps.

      Do you remember the GIF patent affair? The traps don't need to be in an obvious place to be dangerous. Compuserve didn't intend any problems when it allowed the gif format to be standardized, then, after it was common a third party steps in and says "Now about my patent rights...". While I'm fairly certain that Compuserve was innocent in this affair, I don't feel the same way about MS. I expect that they have this already s

  • Java Rivals (Score:3, Insightful)

    by Doc Ruby ( 173196 ) on Saturday May 07, 2005 @10:52AM (#12462082) Homepage Journal
    Pentiums didn't become really high-performance and free of notorious bugs until AMD made Pentium instructions run on a competing processor. Maybe Java needs more competition among virtual processors to see more innovations reach consumers.

  • optimism (Score:3, Interesting)

    by YoungHack ( 36385 ) on Saturday May 07, 2005 @10:59AM (#12462117)
    Wow, I hope this goes well. I've for years felt that Java got a lot of things right (and a few things wrong). But I'll take a C program every time over a Java implementation.

    Why? Because I believe in free software, and I try to use free software. While I might have a practical bone in me that would install Sun's no-cost JVM, it doesn't come packaged with my Linux distro.

    If you want to develop for Java, there's this huge impediment to distributing your software. You've got to get the end user to thunk down an enormous environment first to support it.

    And it doesn't always go well. That's why so many vendors ship with their own JVM. When I installed Oracle last summer, they had done exactly that. Only their bundled JVM didn't work. I ultimately discovered that I could get the software to function by excising that JVM and putting Sun's current offereing in its place. But I would describe the experience as a nightmare, and a less-experienced person would have found it hopeless.

    A common platform, with a free license, that can be packaged by my favorite Linux distro is exactly what Java needs.

    Go team.
    • Python.

      I love Python. I left Java by the wayside when I found Python. I love the sparse look and feel, I love the strength of the language, I love the fact that I don't have to deal with 1000 different indentation styles when I read other people's code, I hugely appreciate all the python modules people have written that implement everything from databases to graphing packages.

      And Python is all over the place, installed and ready to run. My old RH9 system has Python; my Mac has Python; my Windows box ha

  • Harmony could use Parrot (Score:5, Interesting)

    by mattr ( 78516 ) <mattr.telebody@com> on Saturday May 07, 2005 @11:06AM (#12462150) Homepage Journal
    I'm just someone not involved in language development, and so I'm sorry if I'm out of line. Most developers in language X just sit back in admiration at the olypmian efforts of language, compiler, vm or kernel designers. But I would like to humbly suggest that Harmony people talk with the parrot [parrotcode.org] people. Parrot already has a java bytecode converter proof of concept, initial code, will run on tons of platforms, and has perl and python people too. It is GPL compatible and licensable under the Perl Artistic License.

    The reason I suggest this is that it would appear that the main purpose of the Harmony project is to create a vibrant, inclusive community. In that case, the open source world, Harmony, and Parrot, plus users of java, perl, python, ruby and tcl (for starters) can all benefit by combining two disparate groups of all-star programmers working in potentially complementary areas.

    If any parts of the Harmony project can use parts being developed for Parrot, much time would be saved and the quality of both projects could increase. In addition, it would likely be easier for the Harmony project to meet its stated goals of collaboration and sharing of runtime components, etc. to do so with parrot. The Parrot FAQ also talks a bit about VM development, including working with a JVM, it sure sounds like there is some overlap with Harmony.

    Perhaps the Parrot people don't need any help (I doubt they would say so though) and maybe the Harmony VM people can't stand the idea of not building from ground zero, or using only the Apache license and nothing else. If any of these three maybes are true then it is a sad story.

    Also, I may be out of line but it sounds like parrot will enable sharing of code from different languages at runtime. If so that will just magnify what Harmony is trying to do in terms of bringing people together.

    So humbly I would like to say that the ideas of creating a specification and reference implementation, and promoting collaboration and sharing of modular code sounds wonderful, and focusing on these and not wasting time reinventing the wheel could be a great move for Harmony, and contribute to refocusing the brainpower of the free software world, in the spirit of the Harmony and Parrot projects.

    My guess is that Harmony has some really smart people and they are also well aware of the Parrot effort. Maybe some are already involved for all I know. Any comments one way or the other?

    • Re:Harmony could use Parrot (Score:2, Informative)

      by Anonymous Coward
      Good idea, but i think Parrot is designed for dynamically-typed lanuages (perl, python, ruby), wheras java, c# are statically typed.

      Why your own virtual machine? Why not compile to JVM/.NET?
      http://www.parrotcode.org/faq/ [parrotcode.org]
    • The last thing I want to see is the Perl6 project weighed down by another goal. Its bad enough people are wasting so much time toying around with Pugs, which regardless of what you read is throwaway code, yet seems to be capturing the interest of most of the posts on the perl6 lists.
    • It sounds like you're essentially suggesting that open source create something similar to the .NET CLR. It's an interesting idea, but it would be really difficult to get everyone to work together and agree on design details. .NET has the advantage that Microsoft gets to make all the decisions, so when an implementation choice would favor one language over another, they decide based on which language will make them more money. Open source projects won't subjugate themselves when it comes to these kinds of

  • So this is "cool"... (Score:3, Insightful)

    by kryps ( 321347 ) on Saturday May 07, 2005 @11:17AM (#12462191)

    ... and open-source Solaris is "vaporware" even though there is no/nada/nil code available for the Apache J2SE 5.0 implementation. Some people need to have their heads screwed on right.

    -- kryps
    • Yah, it's vaporware. So?

      You think that this is vaporware means that Sun's open-source Solaris isn't?

      You think that this is "cool" means that Sun's open-source Solaris should be?

      Vaporware and cool are orthogonal. Open Source Solaris lost it's chance at "cool" when Sun chose the license they did. It may, eventually, become interesting, or possibly useful. For now it's un-cool vaporware being promissed by a company with a split personality.

  • I'm rooting for them, but (Score:3, Insightful)

    by beforewisdom ( 729725 ) on Saturday May 07, 2005 @11:27AM (#12462246)
    I'm rooting for them, but that is a huge project.

    There is no shortage of half finished FOSS implementations of Java.

    I'll believe it when I see it, and I will be grateful to Apache for making it happen.
  • I just did a backflip. :-)

    This is great news!

    I have several reasons why I like it:

    1) The future financial stability of SUN Microsystems I think is pretty Dark. I think that because SUN is losing on all fronts with its RISC hardware to AMD/IBM's/Motorola's efforts in 64 bit computing during the past couple of years.

    2) Although the best thing I love from SUN is the JCP org, it is not a gurantee that it will continue if SUN is purchased by another corporate entity.

    Quite frankly, as SUN's financial postur
  • Sun has been making noise now and then about open sourcing Java.

    Why not push them toward putting their money where their mouth is?

    Ask them ( or better yet, ask IBM ) to release the java implementations they already have built under an apache license.

    If that is still too liberal for them offer to help in writing a new OS license that will give SUN the control they want.

  • The usual point that comes up with this issue. (Score:3, Insightful)

    by beforewisdom ( 729725 ) on Saturday May 07, 2005 @11:41AM (#12462305)
    Whenever open source and Java come up in a thread someone will always make the point that keeping Java under Sun's control prevents it from being bastardized.

    The example of C starting out as a multiplatform language always comes up.

    This reasoning may be correct, or it may not be.

    I know python implementations are not exactly the same across platforms. There are some things I can do on linux with python that I can't do on windows.

    Are there any examples of multiplatform, open source languages out there, running, that do not require the program to learn about platform specific issues?
    • The only one I can think of is Squeak. And it makes you do everything internal to it.

      Someone above mentioned Perl, but I would wager that the graphic and sound libraries are system specific. With Squeak that isn't true. (OTOH, I've always found the limitations of Squeak...it's Smalltalk language + it's "do everything inside me" + certain limitations of the graphics toolkit ... to be too large a price to pay.)

  • One thing their FAQ doesnt mention (Score:3, Interesting)

    by jonwil ( 467024 ) on Saturday May 07, 2005 @12:15PM (#12462451)
    Is why they cant/wont take code from one or more existing JVMs and libraries and use it as a base.

    We have GNU classpath
    GNU GCJ
    And others

    Why havent we seen anyone take the good bits from all the different Open Source java projects and work on ONE free JVM that will sucessfully pass the Sun J2SE compatibility test (and therefore be a 100% implementation of JAVA)

    Personally, the fact that no Open Source program comes even close to being able to pass the J2SE compatibility test is why I dont write anything in JAVA.

    Most of my code is written in C and C++ with some stuff in Assembler of various kinds.

  • Effort outweights benefits (Score:3, Interesting)

    by rexguo ( 555504 ) * on Saturday May 07, 2005 @12:22PM (#12462501) Homepage
    IMHO I feel the effort can be better spent on helping Mustang (1.6) and Dolphin (1.7) to be better than if Sun did it alone. Just fixing the outstanding bugs that's been on the bug parade is a great service to the Java community. I admire the spirit of wanting to reimplement Java, but this almost feels like a 'Netscape' to me.
    • OK. You help Sun then. No problem.

      This is Free Software (well, FOSS anyway) and that means that you work on the project that appeals to you. Since I don't trust Sun as far as I can throw it (the whole company!) I won't be advocating for them, but you can.

      Were I to push for any one program, I'd push Classpath, but plausibly the Harmony project will eventually be as useful, and it won't be under a restrictive license. I'm certainly not about to tell people not to work on it.
  • You can take their shared source, port it to your platform - far easier than writing a new VM, get the port certified and release it. Look at blackdown.org for example. If you want to "embrace and extend" the VM, just make sure your new language is activated via an optional switch and is not called "Java". I don't see a problem with Sun's license unless you are Microsoft or a hobbyist who wants to distribute a VM without compatibility concerns. Then yes, you should write/have written code from scratch.

  • Interesting project name.. (Score:4, Interesting)

    by salimma ( 115327 ) * on Saturday May 07, 2005 @02:18PM (#12463096) Homepage Journal
    .. does anyone else get a déja vù [kde.org] from the KDE-sponsored attempt to clone Qt back in the non-QPL 1.x days?

Slashdot Top Deals

The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford

Close