On the Horizon: an Apache-License Version of Java 268
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."
great news (Score:5, Insightful)
Re:great news (Score:5, Informative)
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.
Re:great news (Score:2)
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:
Re:great news (Score:3, Insightful)
Re:great news (Score:2)
Never mind all that! They named it after me! After me ME MEEEE!!!
Re:great news (Score:2, Informative)
Re:great news (Score:5, Informative)
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:
Heck, maybe it's just a strategy to get Sun to open Tiger sooner rather than later.
Re:great news (Score:3, Interesting)
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)
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
Re:great news (Score:3, 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 proj
Re:great news (Score:4, Insightful)
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)
Re:Better for the Linux User (Score:3, Interesting)
Re:Better for the Linux User (Score:2, Insightful)
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)
Re:Better for the Linux User (Score:5, Informative)
Re:Better for the Linux User (Score:2, Interesting)
Code management probably should be a facility in modern desktop and serv
Re:Better for the Linux User (Score:2)
Re:Better for the Linux User (Score:4, Insightful)
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.
Re:Better for the Linux User (Score:2, Informative)
Re:Better for the Linux User (Score:5, Insightful)
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
Re:Better for the Linux User (Score:2, Interesting)
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)
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.
Re:Better for the Linux User (Score:3, 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?
Re:Better for the Linux User (Score:3, Insightful)
Furthermore, the absence of an open source and reliable Java introduces a pile of uncertainty to anyone developing J2E
Re:Better for the Linux User (Score:2)
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
Re:Better for the Linux User (Score:3, Insightful)
Re:Better for the Linux User (Score:2)
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
Re:Better for the Linux User (Score:2)
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)
Re:Kaffe, Classpath... (Score:5, Informative)
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)
basic architectural blueprint (Score:4, Insightful)
http://people.apache.org/~geirm/harmony.jpg [apache.org]
reminds me of QT (Score:3, Informative)
Re:reminds me of QT (Score:2)
And I remember (Score:3, Insightful)
Re:reminds me of QT (Score:2)
Re:reminds me of QT (Score:3, Informative)
Excellent! (Score:4, Funny)
#define sleep(a) while(0)
JamVM (Score:5, Interesting)
Re:JamVM (Score:5, Informative)
binary compatibility? (Score:3, Interesting)
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...
Re:binary compatibility? (Score:2)
Being Apache, question is if they will not concentrate on typical serverside libraries, and drop GUI java.
Re:binary compatibility? (Score:2)
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
Re:binary compatibility? (Score:2)
Re:binary compatibility? (Score:2)
I was under the impression that serialized objects were never meant to be portable between different JVMs?
Mono Mono Mono (Score:2, Insightful)
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
Re:Mono Mono Mono (Score:2)
Re:Mono Mono Mono (Score:2)
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.
Re:Mono Mono Mono (Score:2)
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)
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)
optimism (Score:3, Interesting)
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.
As a c programmer, I have one word for you: (Score:3, Insightful)
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)
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)
Why your own virtual machine? Why not compile to JVM/.NET?
http://www.parrotcode.org/faq/ [parrotcode.org]
Last thing Perl6 project needs... (Score:2)
Re:Harmony could use Parrot (Score:3, Insightful)
So this is "cool"... (Score:3, 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
Re:So this is "cool"... (Score:2)
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)
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.
Open Sourced VM Engine (Score:2)
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
Why not have Sun do it? (Score:2)
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.
Re:Why not have Sun do it? (Score:3, 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.
The usual point that comes up with this issue. (Score:3, Insightful)
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?
Re:The usual point that comes up with this issue. (Score:2)
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
Re:The usual point that comes up with this issue. (Score:2)
And of course Squeak has an incredible web development framework - Seaside (http://seaside.st/ [seaside.st]). Try the tutorial -- you will be blown away!
There is a lot of interesting development happening in Squeak at the moment; if you've not played with it in the last couple of years, it's well worth giving it some attention. If you're having trouble getting into Squeak, have a look at some of the t
One thing their FAQ doesnt mention (Score:3, Interesting)
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)
Re:Effort outweights benefits (Score:2)
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.
Re:Effort outweights benefits (Score:3, Informative)
Fortunately Sun does let us fix bugs now.
Take a look at this article:
I fixed the JDK! [javalobby.org]
This guy submitted code fixes and actually got accepted by Sun and rolled into Mustang code!
Wait until Sun gives you trouble (Score:2)
Interesting project name.. (Score:4, Interesting)
Parent uninformed or troll (Score:4, Funny)
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.)
Re: (Score:2, Informative)
Comment removed (Score:5, Informative)
Re:Not GPL compatible (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 [apache.org] 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)
Re: (Score:2)
Compatibility (Score:2)
You can bet the GPLv3 will need it. I think the FSF will quickly find that it is next to impossible even for them to overcome the momentum of GPLv2, because many people have cut the "or later" part. Doesn't it seem wierd to license code under a license you don't even know what is?
Re:Not GPL compatible (Score:2)
Re:Not GPL compatible (Score:2)
Today, there is GPLed java software, I wonder what java that runs on. Running it on a Apache Licenced java engine wouldn't be more of a license violation than running it on Sun java
as they in most cases do today, exept for a very small amount of programs that
Re:MS-JVM all over again? (Score:2)
Re:MS-JVM all over again? (Score:2)
Certainly not "in the Microsoft way". "Embrace and Extend" are perfectly all right - as long as the goal is not "Exterminate" which is Microsoft's method.
Re:Divide and Conquer (Score:3, Insightful)
Also, the point of the sun specification for Java is (in part) to ensure that the JVM performs consistently across platforms.
Re:Divide and Conquer (Score:3, Interesting)
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.
Re:Divide and Conquer (Score:4, Insightful)
I'm sorry, but I'm just really not seeing this supposed "fragmentation" as a barrier to Linux on the desktop.
Re:Divide and Conquer (Score:2)
I've got 2GB's of memory, and starting a gnome desktop with a few KDE apps (k3b mostly), my system consumes a half a GB of memory before I start my services (apache, postgres, mysql, etc.) or application
Re:Divide and Conquer (Score:2)
Re:Divide and Conquer (Score:5, Insightful)
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.
Re:Divide and Conquer (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.
Re:Divide and Conquer (Score:2)
Or put another way "C" is theoretically cross platform but in practice it isn't.
Re:Divide and Conquer (Score:2)
Oh i see, you want me to rewrite my entire program to use this library!
Re:Divide and Conquer (Score:2)
Re:Divide and Conquer (Score:5, 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.
Re:SOUJava? (Score:3, 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
Re:Final Nail In Mono's Coffin (Score:2)
Err, I doubt it. I don't really think anyone is using mono rather than Java because of licensing problems. There are already free implementations of Java that are just as useful as Mono is; the only problem with them is that they're severely lagging behind Sun's Java implementation in terms of new features and APIs.
Re:How? (Score:2)
Why do people complain about the "current" implementations?
Did you use Java the day it came out?
OSS does not spring full-blown into the world. If it takes ten years to get a useful free Java, like it did Linux, what's the problem? You going somewhere?
Re:Hate to say it, but... (Score:2)
Yet another person who doesn't get it...
Did you use Linux the day it came out?
Or Java for that matter?
"It's gonna take years! " SO WHAT? It took Linux over ten years to be a truly useful OS - did you tell Linus and the others to stop ten years ago because "you don't think it's gonna happen"?
"Thirty seven full time work years!" SO WHAT? The project starts with a couple dozen people to begin with - how many more will join if it gains traction? Two hundred? Cuts your estimate to peanuts, doesn't it?
T
Re:Version catchup..... (Score:2)
Again - SO WHAT?
Apache needs something to underpin their numerous Java projects. That stuff runs on what is current Java. So if it takes five years to get a free Java JVM and class libraries, it's no big deal. Even if the Java-based projects move ahead to newer versions of Sun's Java, they won't do so immediately nor completely, so the Apache project can catch up enough to be useful for the Apache Java-based projects.
Also, while Sun is working on the next version of Java, any new project can just watch t
Re:Windows Focus (Score:3, Insightful)
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