Slashdot Mirror
On the Horizon: an Apache-License Version of Java
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."
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
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.
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...
Is JamVM reentrant?
I've been looking for a small JVM that allows multiple independent instances of itself to be kicked off without interfering with each other.
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.
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.
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.
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. 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)
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...
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.
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
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
.. 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
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!