Summary
There have been many calls for open sourcing Java, but that would mean letting go of the requirement for implementations to pass the compatibility test. How important is binary compatibility to you?
Advertisement
Peter Yared recently posted an open letter to Johnathan Schwarz asking why Sun doesn't open source Java. He writes:
The "P" languages in LAMP — PHP, Python, and Perl — are all open source, and each provide their own virtual machine. It would be ideal if the Java JVM was open source so that open source projects like PHP could join up with the Java Virtual Machine.
Later he says:
Can you guys let go a bit and let us all share a single, open source virtual machine?
I don't quite understand this thinking. Does Peter Yared believe that if Java were open source, the P languages would converge onto a single VM, the JVM?
I can run Python code right now on the JVM with Jython. I have wanted to use a scripting language on the JVM on several occasions, for example, for tasks such as writing tests. I haven't done so yet because I have such good IDE support for writing and refactoring Java code. Were I to use a JVM scripting language such as Jython, JRuby, or Groovy, I would today at least lose the nice refactoring support enjoy in my IDE with the Java language. On the other hand, when I want to write an independent script (one not involving any Java API), I write it in Python or Ruby. When I write a Python script, I run it in CPython—the standard Python, runtime, which is written in C—not Jython, because the JVM takes a longer to start up than CPython.
Yared also suggests that if Sun were to open source Java, it would make Java more competitive with Microsoft's .NET:
Java would be much more competitive with .Net, which supports numerous languages out of the box."
And later:
Combining two of the three leading development platforms [meaning: combining Java and LAMP] would make them both more competitive against .Net.
First of all, you can already run many languages on the JVM. I have yet to use any language on the JVM besides Java, because as I mentioned previously, whatever benefit I might gain from the non-Java language hasn't been enough to overcome the loss of refactoring support in my IDE. I would welcome more refactoring support for non-Java languages in Java IDEs, but that certainly wouldn't require Java to be open source.
Moreover, I don't understand what Yared means by "combine" when he suggests open source Java would lead to the ability to combine LAMP and Java. (LAMP refers to the open source technology stack of Linux, Apache, MySQL, and open source scripting languages such as PHP, Python, and Perl.) The page you are looking at was served up by Apache and Tomcat working together on Artima's server, running on Linux. Come to think of it, I also use MySQL and several Python and Perl scripts on that server, all of which work together just fine to bring Artima to the world. So I'm already able to combine Java with all four letters of LAMP quite easily.
A more sensible justification for open sourcing Java that I've heard expressed by others is that it would make it easier for people outside of Sun to contribute to the technology. Sun has tried to open the process to make it easier for outsiders to contribute by creating the JCP and, more recently, by making early access releases available through java.net and reaching out to the community for feedback. But there are still barriers with this approach that may indeed make it harder to leverage the full potential of the community compared to an open source approach. Even if that is true, however, I think that cost is worth paying because in exchange the community gets binary compatibility.
As I understand it, one reason Java cannot be considered OSI-certified open source is that Sun requires an implementation to pass the Java compatibility tests before it can be called Java. I think that's a good thing. There is a ton of innovation going in the Java community, both open source and commercial. That innovation is made possible because at the core of the community there are a few well-defined, well-enforced standards. In addition, those standards have unleashed a vibrant economy of products all of which seem to work together pretty well, and that compatibility very important to me as a consumer.
What is your opinion on open sourcing Java? To what extent do you think the binary compatibility we enjoy today would be threatened by open sourcing Java, and how important is that compatibility to you?
It's seems to me that as long as the VM spec stricly defines what byte codes do, any VM that meets that spec would have binary compatiblity with any other compliant VM. Are you saying that the VM would branch if it were open-source or something else?
On the other hand, I don't see what is stopping the P langs from writing for the JVM now. We already have Jython and JRuby, though they get to the VM through Java, which,of course, isn't really necessary.
> It's seems to me that as long as the VM spec stricly > defines what byte codes do, any VM that meets that spec > would have binary compatiblity with any other compliant > VM. Are you saying that the VM would branch if it were > open-source or something else? > Well I've heard that as an argument as to why Sun doesn't want to open source Java, to which opponents say, but OpenSolaris hasn't been forked. I think you can make an open source implementation of the JVM now, but you can't call it Java unless it passes the tests. So Java can be forked now, but you just couldn't call it Java. I guess my main desire is that the compatibility that comes out of that Sun-controlled licensing process continues, because I really benefit from the compatibility. Because being called "Java" has economic value, vendors make sure they are compatible, which provides more implementations that make it even more valueable to be called Java. That has worked very well in my opinion.
> On the other hand, I don't see what is stopping the P > langs from writing for the JVM now. We already have > Jython and JRuby, though they get to the VM through Java, > which,of course, isn't really necessary.
> forked now, but you just couldn't call it Java. I guess my > main desire is that the compatibility that comes out of > that Sun-controlled licensing process continues, because
But... as long as Sun keeps this rule (ie. "You can only call it Java if it survives the TCK pounding"), then you don't have a problem, do you? Just use the thing with "Java" stamped on it, and be done. If someone does fork off something incompatible... they'll have a very tough time getting it used, because no one will want to use an incompatible version.
This should clarify a few things that people use to get wrong or that people like to confuse in these discussions, most important: the question of "What is Java anyway".
(It's only a bit dated concerning GNU CLASSPATH which has made major steps towards 100 % compliance).
> If someone does fork off something incompatible... they'll > have a very tough time getting it used, because no one > will want to use an incompatible version.
I was going to say the same thing but there remembered that there is a company with the weight to convince a large group of people to do just that. They pretty much already did it. Perhaps this might be part of the reason Sun is a little wary of Open-Sourcing Java?
> that there is a company with the weight to convince a > large group of people to do just that. They pretty much > already did it. Perhaps this might be part of the reason > Sun is a little wary of Open-Sourcing Java?
... I thought MS and Sun were friends now ;) Not to mention that MS has it's own Java (sorry: .NET) now, and they'll be busy promoting that.
> > that there is a company with the weight to convince a > > large group of people to do just that. They pretty > much > > already did it. Perhaps this might be part of the > reason > > Sun is a little wary of Open-Sourcing Java? > > ... I thought MS and Sun were friends now ;) > Not to mention that MS has it's own Java (sorry: .NET) > now, and they'll be busy promoting that.
Sure, but maybe i wouldn't be MS this time. Maybe Google would do it. I'm not saying it would happen just that might be there in the back of the minds of the brass a Sun. I don't think Sun will do it. At least not soon. It would be interesting, though.
As someone who's actually implementing free software VMs, I find the discussion quite funny, both the blog and the reply to it.
A) Binary compatibility is pretty well-defined for Java. It is not what many people think it is.
BC only makes guarantees for linkage symbols, and makes no guarantees regarding the semantics of the symbols. That's why binary compatibility is pretty trivial: just implement all the symbols in an API with their access qualifiers, and you're done.
B) Other languages on the JVM are possible, but serve a largely academic purpose. The JVM design does not allow efficient implementation of languages that are very different from Java.
That has nothing to do with its license, it was simply designed to run Java and nothig else. Retrofitting it do something else leads to pretty ugly workarounds like JNI.
You won't see language implementors flock to the JVM, since its performance is pretty bad compared to native VMs, and one can't drop down easily to C to do things efficiently.
C) Open standards need open test suites. Java does not have that, the test suites are locked away behind "read only" licenses, and NDAs. That's the only reason why the free runtimes are not fully compatible with Sun's VM yet: we have to figure out a lot of things that the so-called 'specifications' don't feel the need to spell out.
Sun does not mind its free software competition wasting time either, so they tend to spend years before they update VM or language specifications to match reality of their implementation.
Quasi-monopolies like Sun can be fun to deal with.
D) The reason why Java is not cosidered open source is that the licensing conditions for the source code do not meet the open source definition by a wide shot. See http://www.advogato.org/person/robilad/diary.html?start=58 for an analysis of the JRL.
> B) Other languages on the JVM are possible, but serve a > largely academic purpose. The JVM design does not allow > efficient implementation of languages that are very > different from Java. > > That has nothing to do with its license, it was simply > designed to run Java and nothig else. Retrofitting it do > something else leads to pretty ugly workarounds like JNI.
Can you provide something to back up this up? It seems like a pretty substantial claim. I'm no expert on byte code but pushes and pops don't seem all that specific to Java.
> > B) Other languages on the JVM are possible, but serve a > > largely academic purpose. The JVM design does not allow > > efficient implementation of languages that are very > > different from Java. > > > > That has nothing to do with its license, it was simply > > designed to run Java and nothig else. Retrofitting it > do > > something else leads to pretty ugly workarounds like > JNI. > > Can you provide something to back up this up? It seems > like a pretty substantial claim. I'm no expert on byte > code but pushes and pops don't seem all that specific to > Java.
The JVM had not changed in substantial ways since 1996, so the findings from
"Supporting dynamic languages on the Java virtual machine. Olin Shivers.
In \emph{Proceedings of the Dynamic Objects Workshop}, May 1996, Boston, Massachussetts. Also available as technical report AIM-1576, MIT Artificial Intelligence Laboratory."
still hold.
For another take, read http://www.inf.ethz.ch/~staerk/pdf/cs03.pdf that explains how far C# semantics can be modelled, and where they blow right past the JVM. Whenever that happens, you can pretty much forget implementing the aspects of the language that you target for the JVM efficiently.
Finally, note the distinct lack of any JVM-targetting language implementation surpassing the mind share of the native ones in the past 10+ years. They have remained a largely academic curiosity.
Given the constraints the JVM is designed for (i.e. running Java well), that is unlikely to change. In particular, radical changes to the JVM, that would optimize it for other languages, would likely introduce problems for verification, migration compatiblity, etc. That's the reason why Neil & the Generics team went for type erasure, rather than tweaking the JVM to support reification.
If you believe that the JVM can be radically changed to support other languages better, then you should ask yourself why the JVM has not been changed in the past 10 years to support the Java language better. The Java language has gradually moved away from the nice almost 1:1 mapping to the JVM-language. The answer lies in the constraints of the Generics JSR.
In other words, we're stuck with Java, and the JVM as they are. If you are looking for the future of Java, you should not be looking at scheme, Ruby, or Python, you should be looking at nice, JML and similar research projects, that gradually evole the language into something that's more useful for writing maintainable code.
> If you believe that the JVM can be radically changed to > support other languages better, then you should ask > yourself why the JVM has not been changed in the past 10 > years to support the Java language better. The Java > language has gradually moved away from the nice almost 1:1 > mapping to the JVM-language. The answer lies in the > constraints of the Generics JSR.
I wasn't doubting your claim per se. It's just that there has lately been a bit of hype around the JVM as a one-size fits all solution for the future. I appreciate the response.
> In other words, we're stuck with Java, and the JVM as they > are. If you are looking for the future of Java, you should > not be looking at scheme, Ruby, or Python, you should be > looking at nice, JML and similar research projects, that > gradually evole the language into something that's more > useful for writing maintainable code.
I've been looking at Scala. Haven't really dived into it, though. I'm learning Python, partly because of Jython (which I find very useful) but more because it has a lot of features that are fairly foreign to me but seem to be common among a lot of 'next generation' languages. I don't know that I think maintainable is what people are looking for, though. Well written Java (of which there is admittedly little) is very easy to maintain. It just takes a really long time to develop. Bad Java is written quicker (like liquor) but is still rather lengthy. I think what people are looking for in these new languages is faster development. I can't see how a large multi-developer project written in a language like Python (which lacks private scope) can be easier to maintain. It seems like writing a dependency checker for Python would be like trying to solve the Turing halting problem.
Your comments made me wonder whether what people really want is a VM designed in an agnostic way such that it's really just a abstraction of a good instruction set. Would this really be an emulator for a non-existant machine? I'm actually struggling to determine whether there is a distinction between emulator and virtual machine in this context.
> I wasn't doubting your claim per se. It's just that there > has lately been a bit of hype around the JVM as a one-size > fits all solution for the future. I appreciate the > response.
Sun's marketing division is great at hype.
> I've been looking at Scala. Haven't really dived into it, > though.
I've heard nice things about Scala, but didn't get around to check it out yet.
> I > don't know that I think maintainable is what people are > looking for, though. Well written Java (of which there is > admittedly little) is very easy to maintain. It just > takes a really long time to develop. Bad Java is written > quicker (like liquor) but is still rather lengthy. I > think what people are looking for in these new languages > is faster development.
When you look at the development Microsoft Research (Rustan Leino, great papers) is doing on Spec#, with static analysis of design-by-contract properties built into the compiler, or MDA with automated role based security code generation from UML+OCL, I think the general idea is that in order to increase maintainability of OO-ish code, one needs to spice up syntax with annotations for desired semantics, and as far as possible automatize enforcing of those annotations, preferrably at compile time. If you can have an automated theorem prover prove that there is no contract violation in your code, that's much better than writing and maintaining tests for it.
In a way, unit tests are just a poor man's way of writing executable specifications for the lack of a better mechanism.
> Your comments made me wonder whether what people really > want is a VM designed in an agnostic way such that it's > really just a abstraction of a good instruction set.
Well, you have to ask yourself what a VM is really good for.
In Java's case, we ended up with a VM mostly because it provides a proven way to ship and run proprietary executables over networks without having to care much what platform is underneath. Java was designed for that application area, so the design choice makes sense.
For other application areas, that's not so important. For example, if you are deploying an application to a specific system, and you have it under control (like a GNU/Linux distribution does), a VM is not very useful, as you still end up running native code all the time, so you may as well ship it precompiled to native, and save your clients the startup and jitting cost of the JVM.
A VM can be useful as an abstraction to write code to. But I'd argue that the quest for the perfect VM instruction set is a bit like te quest for the perfect intermediate represenation in compilers: it really depends on what you want to do and be able to do with it. There is no single optimal choice. For example, see the work done by Michael Franz's research group at http://www.ics.uci.edu/~franz/Site/research.html#idealrep
> Well, you have to ask yourself what a VM is really good > for. > > In Java's case, we ended up with a VM mostly because it > provides a proven way to ship and run proprietary > executables over networks without having to care much what > platform is underneath. Java was designed for that > application area, so the design choice makes sense.
That was the original intent but I think that in reality that is not what most people are doing with Java.
A perfect example of the advantage of the VM is getting software for linux. You can either get the source, get all the libraries it depends on, compile, maybe go on some forums for help to get it working, or hope they have binary for your distribution. With Java, once you have the JRE, you can just get the jars and you are off and running.
I was also thinking that it would be intersting to have a VM with a baseline and with extensions where you could request the hardware use an extended VM with special bytecodes if it supports certain performance enhancements but use the standard version of your bytecode otherwise.
> A perfect example of the advantage of the VM is getting > software for linux. You can either get the source, get > all the libraries it depends on, compile, maybe go on some > forums for help to get it working, or hope they have > binary for your distribution. With Java, once you have > the JRE, you can just get the jars and you are off and > running.
And yet, the majority of software shipped by any GNU/Linux distribution is not in Java. By a far shot. ;)
Why is that? Because deploying Java is a pain, due to the uses and abuses of JARs.
If you try to deploy several Java applications and libraries, they often end up requiring mutually incompatible versions of the same JARs, so that you have to make sure that your $CLASSPATH is properly sorted.
In general, deploying Java works as long as you have the same VM as the author, and the author ships all the binary blobs himself, essentially turning Java applications into what C applications were back in the 80s, when static linking to Motif was en vogue. That's not a big issue, since most people currently only use Sun's VM, though we are changing that with GNU Classpath, Kaffe and gcj. Sort of how shipping C executables statically linked with Motif was probably not a big issue as long as most people used Sparc-Solaris.
Switch the VM, and you're bound for surprises, since a lot of 'enterprisey' Java code out there uses undocumented classes in com.sun* packages which may or may not be present on the officially certified as compatible VM from IBM, or a even a newer release from Sun, for example.
> I was also thinking that it would be intersting to have a > VM with a baseline and with extensions where you could > request the hardware use an extended VM with special > bytecodes if it supports certain performance enhancements > but use the standard version of your bytecode otherwise.
Nice idea, but Sun would never let that pas through the JCP.
If it is not part of the RI, it will only have academic interest.
It allows for platform specific code, and platform speciic code in general does not mean sparc-specific code, so Sun can not sell you their Niagara servers when you need to scale up.
cheers, dalibor topic
Flat View: This topic has 44 replies
on 3 pages
[
123
|
»
]
Previous Topic
