![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small}
A perhaps less controversial plan for creating a better VM
The previous post spawned a lot of discussion, a lot of which was surprisingly technical and on-topic. But after talking with some people I realized that OpenJDK can do a lot just on its own. Here's my wishlist:
OpenJDK->OpenVM plan
- Split up source distribution into OpenVM core, place things like Swing into separate source project
- OS-specific integration in core; e.g. javax.unix namespace (e.g. Unix domain sockets), javax.windows (similar to python-win32), javax.osx; and allow interested operating system vendors to innovate there. The operating system does matter.
- Commit to longer-term VM improvements necessary to allow compilation of C# into extended JVM bytecode (not CIL)
- Commit to VM improvements necessary to make Jython/JRuby work well
- Stay on top of Linux distribution integration, make sure packagers aren't carrying patches (this includes JSR 277 work)
- Together with the above, branding as OpenVM or something similar to express willingness to be more than just the old "Java" which was JVM+Java language+Swing
(Anonymous)
Why not Mono->OpenVM?
1. WinForms (Swing equivalent) and other .NET libraries are already split (you can install Mono without WinForms).
2. It already has OS-specific integration libs (e.g. Mono.Unix).
3. It has all needed to run JVM bytecode (IKVM does it).
4. The DLR provides all needed to run dynamic languages: IronPython, IronRuby.
5. I don't think there are distro specific patches for Mono.
6. The "Mono" name is already language and gui toolkit agnostic.
Re: Why not Mono->OpenVM?
(Anonymous)
Re: Why not Mono->OpenVM?
Re: Why not Mono->OpenVM?
A true shared Free Software implementation is better.
(Anonymous)
Re: Why not Mono->OpenVM?
Just because you can fork it doesn't make it not controlled by them. If you fork, then it's no longer Java (language or VM, depending on which one you fork).
Just like if Mono changes direction from Microsoft's C#/.NET.
Re: Why not Mono->OpenVM?
Re: Why not Mono->OpenVM?
The existence of JCP (and the many years of Free Java) do show that Java isn't dominated by Sun, so they won't be able to dominate OpenJDK like some of their other Open* projects I mentioned in your last post.
Oh, and if you switched to using the default theme for your comment pages you'd get better threading.
(Anonymous)
Re: Why not Mono->OpenVM?
(Anonymous)
Re: Why not Mono->OpenVM?
(Anonymous)
Re: Why not Mono->OpenVM?
So, how can Microsoft's control of .NET hurt Mono/OpenVM? It can't, because if MS changes the API or the CLR to hurt Mono/OpenVM you can just fork like you propose to do with the JDK.
Both the JDK and Mono are free software. Both can be forked. But the JDK needs important improvements to become a real OpenVM, while Mono already has them available. Mono is an implementation of an ISO standard, while the JDK isn't. So, I don't see why the JDK should be chosen over Mono.
Re: Why not Mono->OpenVM?
OpenJDK is Free Software. Yes, Sun has a lot of influence, but they do not (they can't anymore) have ultimate control. The community does.
No, what I'm trying to do right now is convince upstream.
Yes, you can fork Mono right now. But if I wanted to evolve say part of the core class library, perhaps to add a feature that only worked on Linux/Unix perhaps, I would to block on Microsoft.
I think you'll find is that OpenJDK/OpenVM will be a lot more welcoming for Free Software developers. It has a lot of motivation to improve the Free Unix state of OpenJDK/OpenVM and improve integration with the Free desktop, whereas Microsoft has none.
(Anonymous)
Re: Why not Mono->OpenVM?
The exact same thing is true of Mono. It simply chooses, for now, to be as compliant as possible to the spec.
Re: Why not Mono->OpenVM?
(Anonymous)
Re: Why not Mono->OpenVM?
Sure. I just feel like you keep making it seem like Mono has no control over its destiny, when of course it does, and that somehow OpenJDK is more free.
Re: Why not Mono->OpenVM?
The future of computing is definitely VM-based, and the JVM and .NET are going to be around for decades to come. Right now, you have to make a choice which you target if you're writing Free Software. If Mono and OpenJDK were to work together, the choice would be clear - OVM.
Anyways...we'll see what happens.
Re: Why not Mono->OpenVM?
(Anonymous)
Re: Why not Mono->OpenVM?
If you want OpenVM to stay compatible with the .Net VM wont you have exactly the same burden of following MS' lead?
As explained, I can't see any advantages to OpenVM over using Mono/IKVM. Please explain if I've missed something.
If you're worried about MS patents and influence, ignore .Net, use something else.
Anyways, good luck convincing people to re-invent the wheel, will be a fun project.
For me in the meantime, I'll just stick to Mono/IKVM.
Re: Why not Mono->OpenVM?
You'd really use Mono+IKVM to run a Java/JVM application over OpenJDK? Why?
(Anonymous)
Re: Why not Mono->OpenVM?
> with the other communities in the Free Software
> world like Python and Ruby. I would argue that
> OpenJDK is a lot more likely to be better at that,
> because it's a Free Software project itself.
Mono is also a Free Software project.
> The issue I have is control over the class
> library. Microsoft is very likely to add things
> to .NET that are not in Free Software's interest,
> like Direct3D
So what? Mono is not forced to implement those libraries. If that's the only issue you have, that's a non-issue.
From the technical point of view there is no reason to choose JVM over Mono. Mono is better suited for an OpenVM because it has been designed to be a more generic VM than the JVM.
Regarding the freedom of the projects, both Mono and JDK are free software. Both have communities of developers you can reach through IRC, as you request.
The API being controlled by a company is not an issue since OpenVM is not forced to implement all the API. OpenVM can have its own stack of libraries.
So, what's left? only personal feelings. You don't like Mono because if comes from Microsoft technology, it is that simple. I understand it since it is a popular and comfortable position. But it makes also clear that your proposals about OpenVM are not as objective as they should be.
Re: Why not Mono->OpenVM?
Not quite - if it was controlled by Apple, I would be just as against it. Both Microsoft and Apple, remember, are in the proprietary operating system business. They are what Free Software is fighting against in particular.
(Anonymous)
Re: Why not Mono->OpenVM?
If someone goes to push you, what do you do? You use their attack against them. You pull.
If Free Software developers fight proprietary software tooth and nail, they won't win developers over. If they don't win more developers over, they can't hope to bring more end-users over en-mass.
It seems that Miguel is smart enough to realise this, and that's why Mono has been so successful.
You are making a mistake discounting Mono so easily. Making the case that they should bend over and drop their project to go and help a competing company on theirs (where they are unlikely to have as much control as they have now) is also unlikely to go over well.
Despite what you may think, Miguel & team have all the power they want with Mono, they can change direction from Microsoft any time they wish.
In fact, they already have - that's what Mono.Unix, Gtk#, etc are all about.
Since you brought up Direct3D, have you looked at Tao? Mono already has OpenGL bindings along with OpenAL, SDL, etc.
Just because Microsoft may add Direct3D bindings doesn't mean people have to use it.
Your arguments against using Mono make absolutely no sense.
You claim that we can't use Mono because it's controlled by one company - exactly like Java.
You claim that we can't use Mono because patents, yet later, after suggesting OpenVM be based on the JVM, you suggest making C# and the .NET class libs be ported to the new VM - as if that negates the patents? Huh??? And later still you claim you don't pay any attention to patents. Well, which is it?
You claimed in your previous blog comments that KDE couldn't merge with GNOME because of license differences. Mono is LGPL/X11, you say that the JVM is GPL. That's pretty much the exact same license differences between GNOME libs and KDE libs.
Your arguments are so hypocritical it makes the mind numb. I could go on and on about your arguments, but I hope you get the idea.
Re: Why not Mono->OpenVM?
I never said you can't use Mono. I said that I believe it's a long-term bad idea for Free Software to be based on technology that is controlled by one proprietary software company, particularly one that is a competitor to the Free desktop.
I don't think everyone must stop using Mono right now, and in fact I use Tomboy myself.
Except in the case of the JVM, the primary implementation is Free Software, and the company with the most influence on it is far more in the Free Software camp than Microsoft will ever be (even though they clearly have some factions).
I never said that. Many other people have said that, but I did not. What I *did* say is that I try very hard to ignore patents, because I am not a lawyer. I do not know ultimately how important the patent issue is with respect to Mono, and that's why I never said anything about it and don't plan to.
Actually the JVM is GPL+exception, which is very close in terms of permissions to the LGPL. Now, both companies here have full copyright and could relicense I believe too. If Mono wanted to keep the X11 license, it doesn't seem farfetched to imagine Hotspot being relicensed compatibly.
Re: Why not Mono->OpenVM?
I bet someone could implement a java class lib that closely or even perfectly match the CLR class libs in Java, C++ or C# without ever dealing down into the runtime.
I think we need to investigate _that_ idea. Project Sauron - a class lib to rule them all. Such that it was a superset of all the other class libraries written in Java, C# AND C++. Wrap them up in front of the runtime libs or write them from scratch.
Of course we have that now - Qt runs on top of the JVM (Qt/Jambi), Mono Runtime (Qyoto) and as a C++ class lib (Qt itself with Smoke to allow bindings to many languages natively).
(Anonymous)
Another is simply that many companies and communities are behind the JVM ecosystem; IBM, Google, Adobe, Red Hat, Sun, Oracle, and many many more. Novell also particpates in many JCPs. Long term, the JVM is going to improve.
It's a huge advantage to the Free Software community if the technology base we're using is *the* upstream, because we don't have to invest tedious effort into cloning things like Windows.Forms anymore; Swing is now Free.
(Anonymous)
And why would the forked Mono VM be bound to implementing things like Windows.Forms?
That argument was way out of left field.
On things like Windows.Forms - remember, the class library is key. It's going to be very tempting for third party developers to write to Windows.Forms. Here's a question. Do we want the next Picasa to be written to Windows.Forms, or SWT/Swing? I'd strongly argue we want the latter, because both of the *primary implementations* are now Free Software that *we control*.
(Anonymous)
JVM is on the way already to doing most of that
Mono does have faster startup times, and takes less memory on average. So things aren't black and white. Still, from a technical point of view the JVM would be my choice.
Now, as for your plan, well the JVM is on the way to doing all or most of those. Except perhaps for changing the name. But given Sun's generosity in GPLing the JVM, I for one will overlook that. Even if our FOSS VM ends up being called "Java VM", it will be about as confusing as "Javascript" having nothing to do with Java either. We can live with that.
Perhaps the critical issue would be getting C# running well on the JVM. Get that done, and do a quick port of the Mono .Net libraries, and the JVM will be the obvious choice.
(Anonymous)
Re: JVM is on the way already to doing most of that
The only benchmarks I know of (the Debian Language Shootout) has Mono performance neck-and-neck with the Sun Java 6 performance... and as you mentioned, the Mono VM uses less memory on average than the JVM.
Perhaps you are referring to the old C# Regex and BigInteger tests?
You should try reading Miguel's blog about that - turns out that the Java implementation of the BigInteger test was using libgmp rather than a managed BigInterger class.
One the Java implementation was ported to C# and re-run on the Mono VM, the results were that it was equally as fast under Mono as it was under the JVM (not really a surprise, seeing as how all the time was spent in libgmp).
The Regex test is really more of a test of the regex class implementation performance than the VM performance, but a few weeks ago, a couple of Mono developers spent time optimizing the System.Text.RegularExpression engine to properly compile the regex into bytecode for the VM. Previously, from my understanding, the regex was always being interpreted whenever the Match method was invoked.
From my recollection from reading Miguel's blog, Mono's Regex implementation is now quite a bit faster than Java's - coming in as #2 for performance, just behind tcl iirc.
(Anonymous)
Re: JVM is on the way already to doing most of that
In particular, since you talk about P/Jython and J/Ruby running on this same VM, the recent work on IronPython/Ruby and Jython/Jruby seems relevant.
From what I understand the Mono/.NET VM needed a DLR built on top of their CLR because it simply didn't have the dynamic abilities that the JVM has built in (though not yet fully exploited).
There's a great deal more detail here, particularly in the section "A Solid Base":
http://headius.blogspot.com/2008/01/lang
In his final three points he (a Sun employee if that's not obvious) basically calls for exactly the same things cgwalters does in regards to making the JVM a better, more open, multi-language VM.
Re: JVM is on the way already to doing most of that
I think it is pretty clear is that for the forseeable future, both JVM and .NET are going to be around. There are very large forces (both corporate and community) arrayed behind both of them. The question is what parts of the Free Software community will unify. CPython and CRuby don't make long-term sense, for example.
(Anonymous)
Re: JVM is on the way already to doing most of that
> be so much discussion when the JVM seems to be
> clearly technically superior
That's largely debatable. .NET fans will tell you that the CLR is superior. Java fans will tell you that the JVM is superior.
In any case, it is a matter of fact that the CLR was designed from scratch to be a language agnostic and multi-purpose VM, while the JVM was not. The CLR is more modern, and doesn't have many constraints that the JVM has in order to be backwards compatible. One clear example is how generics are implemented in both VMs. The Java implementation of generics is a joke, clearly inferior to CLR's implementation.
> From what I understand the Mono/.NET VM needed a
> DLR built on top of their CLR because it simply
> didn't have the dynamic abilities that the JVM
> has built in (though not yet fully exploited).
That's false, you don't get it. IronPython was created several years ago, and proved to be highly performant, which proves that the CLR provides very good support for dynamic languages. The DLR is the result of extracting from IronPython a set of utility classes which are not python specific, so they can be reused by other dynamic languages. They are just additional libraries, they are not CLR improvements.
> In his final three points he (a Sun employee if
> that's not obvious) basically calls for exactly
> the same things cgwalters does in regards to making
> the JVM a better, more open, multi-language VM.
And it is interesting that he makes those tree points after attending the Lang.NET symposium. The CLR is already a multi-language VM, and is quickly moving forward to improve support for dynamic languages. Java is playing catch-up here.
(Anonymous)
Re: JVM is on the way already to doing most of that
For all of the "Mono will always be playing catch-up to Microsoft's .NET", Sun's Java (language /and/ VM) are in the same boat.
(Anonymous)
Re: JVM is on the way already to doing most of that
No doubt, it is easier to base the OpenVM on Mono than the JVM since CIL is pretty much a superset of Java bytecode. Of course, few Java people will admit to that. lol