Slashdot Mirror

← Back to Stories (view on slashdot.org)

On the Horizon: an Apache-License Version of Java

Posted by timothy on 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."

63 of 268 comments (clear)

  1. great news by Sv-Manowar · · Score: 4, Insightful

    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

    --
    Business Voyeur
    1. Re:great news by timeOday · · Score: 5, Informative
      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, 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.

    2. Re:great news by genneth · · Score: 2, Informative

      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.

    3. Re:great news by steve_l · · Score: 2, Interesting

      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 can get hold of the Java1.5 Test Kit. Sun have given teams access to other TCKs (Axis and Geronimo, for example), so it may be possible. If we can do that, we may have a chance.

      Wine has a harder problem, in that the Win32 is only implicitly specified by the behaviour of the system. Java is a lot cleaner, and was designed for portability from day one. But some bits of the JDK are probably badly specified; that will surface eventually.

      steve loughran.
      (apache member, but not (yet) involved in harmony)

    4. Re:great news by Taladar · · Score: 2, Insightful

      You are right about "good enough" although I think the Sun Implementation is a perfect example of this "good enough" quality and far from perfect.

      --
      Linux is not Windows
    5. Re:great news by Master+of+Transhuman · · Score: 2, Insightful


      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 projects Apache is supporting which are Java based, this is a good idea. It can only improve the spread of these OSS projects if the underlying language is also open source.

      Another concept that should be explored is porting these Java projects to Mono - assuming that Miquel can keep the Mono project from being sued out of existence by Microsoft at some point.

      --
      Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
    6. Re:great news by afabbro · · Score: 3, Insightful
      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...

      --
      Advice: on VPS providers
    7. Re:great news by wfmcwalter · · Score: 5, Informative
      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.

      --
      ## W.Finlay McWalter ## http://www.mcwalter.org ##
    8. Re:great news by AstroByte · · Score: 3, Interesting
      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 for some good papers). In fact, the difference between a poor interpreter and a good interpreter can be greater than that between an intepreter and a JIT.

      Several improvements over a switched interpreter are possible. Firstly, indirect-threading can be used to minimise dispatch overhead. This can further be improved by moving to direct-dispatching, but this requires rewriting the original bytecode stream. Splitting instruction fetch and address computation via prefetching can also lead to substantial gains, as can the use of "super-instructions".

      Additionally, an interpreter can attempt to do stack-caching (either simple top-of-stack caching or more advanced 2 or more levels). This can be used to overcome the inefficiency of executing stack-based bytecodes on a register-based CPU.

      Many of these techniques move into the grey area between interpreters and JIT compilers. But no commercial VM uses a simple bytecode interpreter. Even with a JIT, modern VMs still initially execute code using the interpreter, only compiling the "hot spots" to native code. With full JIT compilation, the start-up time of the VM becomes prohibitive.

      Many of these techniques are also used in some of the open-source VMs. For example, the interpreter in JamVM, depending on architecture, makes use of direct-dispatching, super-instructions, prefetching, and true, 2 level stack-operand caching. It is many times faster than a simple bytecode interpreter, and it has not been trivial to implement!

  2. Better for the Linux User by MoogMan · · Score: 5, Insightful

    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).

    1. Re:Better for the Linux User by Chris+Kamel · · Score: 3, Interesting

      Don't you think a reimplementation of the VM is too much of a price to pay for such a small convenience?

      --
      The following statement is true
      The preceding statement is false
    2. Re:Better for the Linux User by petermgreen · · Score: 2, Insightful

      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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    3. Re:Better for the Linux User by IamTheRealMike · · Score: 3, Insightful

      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?

    4. Re:Better for the Linux User by IamTheRealMike · · Score: 5, Informative

      Right, but so what? It can "run" .class bytecode files by compiling them to native code on the fly, this is how gcjwebplugin works AFAIK. The difference between a VM and compiler is mostly one of semantics, there's no compelling enough reason to reimplement the VM.

    5. Re:Better for the Linux User by DrXym · · Score: 4, Interesting
      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.

    6. Re:Better for the Linux User by beforewisdom · · Score: 4, Insightful

      "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

    7. Re:Better for the Linux User by williamhb · · Score: 2, Interesting

      There is a compelling reason for some VM functionality to become part of the operating system. For a long time, memory management [in terms of making sure one app cannot tread on another app's memory even if it is badly written] has been a function of the OS. Providing garbage collection to ensure that one process cannot expend available memory with leaks (affecting the performance of other processes) is a sensible extension of this.

      Code management probably should be a facility in modern desktop and server operating systems. (But perhaps not small embedded systems). At that stage it makes sense for your distributed binary to be compiled to code for the VM/OS rather than compiled to the VM/OS+CPU combination. The VM, either through compilation at install or JIT compilation can then optimise it for the CPU (hello Gentoo-like optimisation on downloaded packages!).

      Whether Linux should provide that with Mono or Java is an open question. Personally, I would prefer Java [for the selfish reason that I know Java very well], but "both" is probably the right answer. This gives support for both sets of programmers, and some protection against one of the technology-patenters going rampant...

    8. Re:Better for the Linux User by petermgreen · · Score: 2, Interesting

      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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    9. Re:Better for the Linux User by Master+of+Transhuman · · Score: 2, Insightful


      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?

      --
      Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
    10. Re:Better for the Linux User by FireBreathingDog · · Score: 3, Insightful
      Garbage collection can't guarantee code that's completely free of memory leaks. You can still leak memory in Java is you have a long-lived data structure (Set or Map, for example) that holds references longer than it needs to.

      Let's say you've got an improperly written session management routine where users are added to a Set when they log in, but there's a bug that forgets to remove them when they log our or their session expires. Over time, you'll start having memory issues.

      Of course, it's still true that there's much less likelihood of leaks in a GC environment.

      --
      Shame on Google.
    11. Re:Better for the Linux User by javabsp · · Score: 2, Informative

      I believe that gcjwebplugin actually uses gij to interpret the byte code. The standard libraries are compiled to native code, but the applet classes aren't.

    12. Re:Better for the Linux User by DrXym · · Score: 2, Insightful
      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 J2EE apps who's investigating what platform to deploy it on. Much as I dislike Solaris, I'd probably use Sun if I were deploying J2EE stuff simply because Sun have obligation to support Linux or ensure the performance is on par with Solaris.


      Just as bad, because there is no open source Java in wide use, Sun can chop and change theirs as they see fit without fear of breaking anything. Just look at the effect that Apache, gcc have on their commercial counterparts to see what I mean.


      So yes time is important. Either Sun needs to open up their Java (or classes) or a viable open source version needs to appear. And by viable I mean totally interchangeable. Ten years delay means billions and billions of dollars that would have been invested in Linux in one form or other go somewhere else.

    13. Re:Better for the Linux User by greenrd · · Score: 2, Insightful
      I sincerely doubt they would cut off Linux support within the next decade or so. Seriously. It can't cost that much to support, and the userbase of Java-on-Linux must be huge. Besides, OpenSolaris is going to be open sourced in a few months, so Sun wouldn't make a lot of money if they forced people to switch to Solaris.

      --
      Female Prison Rape in NY
  3. Kaffe, Classpath... by otisg · · Score: 3, Informative

    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.

    --
    Simpy
    1. Re:Kaffe, Classpath... by Fefe · · Score: 4, Informative

      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.

    2. Re:Kaffe, Classpath... by Anonymous Coward · · Score: 3, Informative

      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 completeness is 99% of the problem.

  4. basic architectural blueprint by anandpur · · Score: 4, Insightful


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

  5. reminds me of QT by moz25 · · Score: 2, Informative

    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. It never got off the ground though.

    --
    see a Text Widget
    1. Re:reminds me of QT by eurleif · · Score: 3, Informative

      There are issues with it for non-commercial software which isn't GPLed. There aren't issues with it for commercial software which is GPLed. GPL != non-commercial.

  6. Parent uninformed or troll by Chris_Jefferson · · Score: 3, Funny
    The link you post to is the FSF's problem with Java's current licence. Their actual opinion on the Apache License v2.0 is below. It's incompatable due to patent related issues that the GPL doesn't (and probably should) deal with. It's a fine free software license:

    Apache Software License, version 2.0

    This is a free software license but it is incompatible with the GPL. The Apache Software License is incompatible with the GPL because it has a specific requirement that is not in the GPL: it has certain patent termination cases that the GPL does not require. (We don't think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)

    --
    Combination - fun iPhone puzzling
    1. Re:Parent uninformed or troll by squiggleslash · · Score: 2, Informative
      If that were true, then Apache wouldn't be usable in the free world.

      The truth is the opposite of your stance. Apache wants a free Java because an enormous amount of back-end web code these days is written in Java. As such, they need a Java interpreter that "plays well" with Apache. That means something licensed under the ASL2, which, like the GPL, is a Free Software license.

      If they licensed it under the GPL, then the question of how well it could legally integrate with Apache would come up.

      Long term the solution to this almost certainly lies in the GPL3, which will alleviate many of the issues that forced the Apache people to put together an alternative license to begin with. But for now, looking at the circumstances, this is one of those rare cases where a license that happens to be incompatable with the GPL is appropriate.

      (And, FWIW, I speak as someone accused of being a GPL zealot on a regular basis. I love the GPL. For most projects, providing the GPL as the license or a license a user can choose as an alternative, seems absolutely appropriate.)

      The ASL2 is a Free Software license. It's not compatable with the GPL, and incompatabilities do undermine freedom, but when choosing between it and the GPL, you have to look at what critical code it will have to interact with. Had they choosen the GPL, it would arguably have undermined freedom far more than the choice they made.

      If you want GPL compatable Java, take a look at GCJ and GNU Classpath. There are people working on both these and Harmony. They are cooperative. This project is helping freedom, not working against it.

      --
      You are not alone. This is not normal. None of this is normal.
  7. Re:Not GPL compatible by squiggleslash · · Score: 4, Informative
    In case you're serious, the Apache Sofware License 2.0 is considered a Free license, just not a GPL compatable one. The FSF actually quite likes it:
    This is a free software license but it is incompatible with the GPL. The Apache Software License is incompatible with the GPL because it has a specific requirement that is not in the GPL: it has certain patent termination cases that the GPL does not require. (We don't think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)
    It's quite probable that once version 3 of the GPL is released, there'll be a strong effort from both sides to get some compatability between the two as incompatable licenses hurt everyone, whatever your ideological differences. Version 3's important because it's the one the FSF has suggested it'll deal with the issue of patents in.

    In the mean time, the Apache group's choice of license for their Java project makes perfect sense given a major, if not the major, use for Java these days is for back-end work of web-fronted applications. Apache's Tomcat sometimes seems to be more popular than Apache itself. (I said seems people, seems); I can't think of any other reason why the Apache people would be organizing this, though it surprises me they're going for J2SE and not J2EE compatability.

    So, no. There's no "Java trap" inherent in developing code for Apache Harmony.

    --
    You are not alone. This is not normal. None of this is normal.
  8. Re:Divide and Conquer by maharg · · Score: 2, Insightful

    The great beauty of the linux desktop is that it, like all *x desktop windowing systems, is not standardised - and therefore, you don't have to use a bloated implementation. Personally, I use openbox, which as about as far from bloated as you can get (assuming you something a little more sophisticated than twm..).

    Also, the point of the sun specification for Java is (in part) to ensure that the JVM performs consistently across platforms.

    --

    $ strings FTP.EXE | grep Copyright
    @(#) Copyright (c) 1983 The Regents of the University of California.
  9. Excellent! by multipartmixed · · Score: 3, Funny

    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. ;)

    --

    Do daemons dream of electric sleep()?
  10. Re:Divide and Conquer by multipartmixed · · Score: 4, Insightful

    C *is* cross-platform.

    The system libraries, on the other hand.. well, that has nothing to do with the language. If you want cross-platform code, use cross-platform libraries.

    If you can stick to using only functions in K&R and the POSIX Programmer's Reference Guide, you will find that your code (if written properly) will run damn near anywhere.

    If you want a little more functionality (as much as you need, really) without GUI, adding the Apache Runtime Library will get you there -- portably. Especially under unices and workalikes.

    C++ -- I'm not qualified to comment on that.

    --

    Do daemons dream of electric sleep()?
  11. Re:Not GPL compatible by hexene · · Score: 3, Informative

    I can't think of any other reason why the Apache people would be organizing this, though it surprises me they're going for J2SE and not J2EE compatability.

    But they are. J2EE is a superset of J2SE, and by adding Apache Geronimo you'd get the complete stack. Admittedly Geronimo is aiming for J2EE 1.4 rather than J2EE 5.0 at the moment, but J2EE 5.0 doesn't really exist yet. ;o)

  12. Re:Divide and Conquer by Khalid · · Score: 2, Interesting

    The great beauty of the linux desktop is that it, like all *x desktop windowing systems, is not standardised

    Alas this is also one of its main weakness. I had once high hopes for Linux on the desktop (three of four years ago), but the way I see it now is that its more fragmented than ever. I think it will manage to reach something around 5% share of the market in four or five years, but the bulk of the users will probably just stay with Windowz.

  13. Re:Divide and Conquer by marcosdumay · · Score: 2, Informative

    "C++ -- I'm not qualified to comment on that."

    C++ also have an ANSI standard. So, if you code following ANSI C++ and POSIX, your program should run on every unix (and NT). But C++ compilers are known to not following standars, so it is not that good.

    --
    Rethinking email
  14. JamVM by Hugo+Graffiti · · Score: 5, Interesting
    I hope they choose JamVM 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.
    1. Re:JamVM by shutdown+-p+now · · Score: 4, Informative

      No JIT, though. Which makes it nearly useless on the server, where Java is mostly used.

  15. binary compatibility? by palinurus · · Score: 3, Interesting
    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...

  16. Re:Divide and Conquer by ssj_195 · · Score: 3, Insightful
    What is "fragmented" about it? If you have a computer with more than 256MB of RAM, then you can happily run either KDE or GNOME - the difference is merely one of personal preferences. An application written for GNOME works damn-near perfectly under KDE, and vice-versa, due in large part to the efforts of freedesktop.org. If you are talking about distros, then the only two that a "Joe Sixpack"-type of home user will need to know about are Ubuntu and SUSE (I'd go with Ubunutu, personally). Granted, packages are not interoperable between the two, but since both have good, up-to-date versions of the same software a mouse-click away, who cares?

    I'm sorry, but I'm just really not seeing this supposed "fragmentation" as a barrier to Linux on the desktop.

  17. Mono Mono Mono by synthespian · · Score: 2, Insightful

    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 doesn't even have a standard by a credible overseer, like ISO, ANSI or ECMA?

    This is perpetuating the Java/Sun dependency. Kick the habit!

    --
    Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
    1. Re:Mono Mono Mono by HiThere · · Score: 2, Insightful

      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 set up, with a patent pool agreement covering them against their partner.

      I could be wrong, but MS isn't a trustworthy partner, and Mono is taking their bait. It *could* be innocent this time, but that's not the way to bet.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    2. Re:Mono Mono Mono by synthespian · · Score: 2, Insightful

      Mono is just Java with minor alterations.

      On the surface. However, on the Common Language Runtime, there's huge difference. You're one of those people who haven't read anything substantial on Mono, and dismiss it quickly on wrong premises.

      --
      Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
  18. Java Rivals by Doc+Ruby · · Score: 2, Insightful

    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.

    --

    --
    make install -not war

  19. optimism by YoungHack · · Score: 2, Interesting

    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.

  20. Re:SOUJava? by bluGill · · Score: 2, Interesting

    Read the FAQ. In short, the contributors will decide what to do.

    Since most of the people on this project are involved with some other java project, they can at the very lease re-license their own source code, and that might be enough to get most of the other code into the Apache license. One would presume that they also have contacts with most of the other developers, and might be able to talk them into license. That covers the legal issues.

    There is one other issue. These people have experience with one implementation. One presumes that along the way they have learned from their mistakes. They might decide to throw it all away (see mozilla) because now they know how to do it right.

  21. Harmony could use Parrot by mattr · · Score: 5, Interesting
    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 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?

    1. Re:Harmony could use Parrot by Anonymous Coward · · Score: 2, Informative

      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/

    2. Re:Harmony could use Parrot by curunir · · Score: 2, Insightful

      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 decisions. It could very easily end up in a situation where everyone argues and nothing ever gets done right or done at all.

      Something like that stands a much better chance of happening if someone just goes off and does it. It would be neat if this new JVM includes an extension mechanism that allows people to write JIT compilers for other languages. But I just don't see Java users getting behind a runtime that doesn't place Java concerns ahead of all else. So I think it's doubtful that Parrot itself would ever end up being used as the basis for a new JVM.

      --
      "Don't blame me, I voted for Kodos!"
  22. So this is "cool"... by kryps · · Score: 2, Insightful


    ... 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

  23. I'm rooting for them, but by beforewisdom · · Score: 2, Insightful

    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.

  24. The usual point that comes up with this issue. by beforewisdom · · Score: 2, Insightful

    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?

  25. And I remember by Julian+Morrison · · Score: 2, Insightful

    ...that project Harmony was the reason TrollTech chose to GPL (as versus seeing their strategic role usurped by an LGPL workalike). At which point Harmony dried up as redundant. So while it didn't per se do much, its historic impact isn't negligible.

  26. One thing their FAQ doesnt mention by jonwil · · Score: 2, Interesting

    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.

  27. Effort outweights benefits by rexguo · · Score: 2, Interesting

    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.

    --
    www.rexguo.com - Technologist + Designer
    1. Re:Effort outweights benefits by rexguo · · Score: 2, Informative

      Fortunately Sun does let us fix bugs now.

      Take a look at this article:
      I fixed the JDK!

      This guy submitted code fixes and actually got accepted by Sun and rolled into Mustang code!

      --
      www.rexguo.com - Technologist + Designer
  28. As a c programmer, I have one word for you: by fyngyrz · · Score: 2, Insightful
    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 has Python.

    Python. C when you have to have the performance, certainly. Python otherwise. :-)

    --
    I've fallen off your lawn, and I can't get up.
  29. Re:Divide and Conquer by Master+of+Transhuman · · Score: 4, Insightful


    I shouldn't have posted above while I had mod points, since this troll crap is modded "Insightful" by the Windows trolls moderators and other idiots.

    Look, stupid, this is not just a "licensing fetish" (although as has been discussed, there is a perfectly good reason for Apache to not use the GPL or like Sun's license.)

    The point of this project is to provide a compatible free Java that Apache can use to underpin its numerous Java-based projects.

    It's an excellent idea - unless Sun ever comes out with a truly OSS license. And if they do, it will probably be because such a project is gaining traction.

    --
    Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
  30. Re:Why not have Sun do it? by Master+of+Transhuman · · Score: 2, Insightful


    If Sun ever does do a completely OSS license, projects such as this are likely to be the cause.

    That alone justifies the project.

    --
    Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
  31. Re:Windows Focus by mccalli · · Score: 2, Insightful
    If windows is not the target operating system. I see failure or at lease non-support.

    Windows isn't where the main focus of Java use is. True, deployment of GUI apps is getting nicer with webstart and what have you, but the real focus is on the server side. And that means Linux and Solaris.

    The Sun Solaris JVM, for example, is an utter pig to tune. It requires some of the most obscure settings imaginable, and by the time you're finished learning some virtual machine backwards you may as well have written it for the metal anyway (disclaimer: I develop in Java, the apps I write tend to need passable processing done with latencies of under a millisecond. The machines we use are big).

    With Apache themselves being primarily on the server side, I would have thought they'd be concentrating on the various Unix derivatives first - with particular focus on Linux and Solaris.

    Another interesting point - IBM have tended to use the Apache foundation to get open source code to the world through. I wonder if they're thinking of donating as much as they can (by license) of their own JVM?

    Cheers,
    Ian

  32. Interesting project name.. by salimma · · Score: 3, Interesting

    .. does anyone else get a déja vù from the KDE-sponsored attempt to clone Qt back in the non-QPL 1.x days?

    --
    Michel
    Fedora Project Contribut