On Apr 19, 2008, at 6:28 AM, Patrick Wright wrote: >> - Discussion of the JVM language list, the JVM language runtime, Da >> Vinci Machine and JDK7 work, and other research helping languages >> in the >> future. This will show how we're all trying to cooperate to solve >> the >> problems of language impl on JVM. > > What I'd like to hear about here is what Sun's commitment is to the > MLVM outside of the invoke dynamic JSR. I'm excited to see the > proposals that John Rose has been blogging about,
I am pleased that you are excited about the proposals, and I'm excited too. I've been dreaming about them for years. None of them are fundamentally original; the question is whether their time has come (once again, sometimes after 20 years). Some of them are based on ideas worked out in my pre-Java Scheme VM, which (before the days of open source) never made it outside the corporate firewall. But now such work can be community based. It is a good time to be a language designer and a VM implementor. > but the catch is > that any of those that require JVM changes require a JSR, an expert > group, and approval by the JCP--which includes other JVM implementors > who have to agree to update their JVMs to support those features > (including heavyweights like IBM, for example). There are Java customers who will not use MLVM features until they are multiply sourced, and that means JCP work. JCP work is slow and can be contentious. It works best when there is a working technology with simply demonstrable advantages, as with Pack200 (my other JSR). The mlvm (aka Da Vinci Machine Project) is our incubator for VM/ language technology advances before and during the corresponding JCP work. If necessary, we can take the time we need to prove by experience that some feature (say, anonymous classes) is really useful. So it's a compromise. If the case for feature X can be clearly made, all the JVM vendors will be able to standardize on X. Otherwise, those of us who believe in X can still work on it, and the standard may lag behind. That's one reason we need emulation modes for things like method handles and invokedynamic. > The worst that could > happen is that the MLVM ends up like the ill-fated Barcelona project > (multi-app VM), interesting research, interest from the > community...abandoned. That would be bad. I've been at Sun for 20 years, doing language and VM work the whole time, and I've never seen a better channel for getting new VM technology into customer hands. The key is that you guys can vote with code, by contributing VM code and/or using it in language implementations. That's the strength of open source. I trust it is sufficient to keep the work alive. > Knowing how far Sun is willing to go in pushing > this is important in knowing the range of languages that can > realistically be supported on the JVM in the future. You're probably > in a good position to get some info on this and share it with the > crowd. It's hard for me to talk about Sun pushing stuff. I'm not expert about such things; I prefer pull to push. (Pack200 was a simple case of the objectively best compression technology, pulled from my desk drawer, past a couple of prior efforts, into a standard. JSR 292 is not nearly so objective, but I still think people will ask for it.) Personally, I just keep on trying to build good designs and implementations, hoping they will make users' lives easier. Here's how I think it works in this case: VM vendors listen to customers. If customers want dynamic language implementations, and new standard VM features to support them, they will figure out how to work the JCP process to create the standards. Conversely, nobody has time for JCP work that customers aren't asking for. JVM support for non-Java languages is a well understood problem. We have the motive and now the opportunity to fix it as a community. Sun is sponsoring the effort, as a natural synergy with the open- sourcing of HotSpot. Sun gets accused from time to time of throwing its weight around. (Do we look fat?) The reality is we try to figure out what customers would like, and help build it. I hope customers will pull JVM support for new languages from the relevant parts of the Java ecosystem, including Sun. We are eager at all corporate levels to supply such things. So if you pull we'll push. Check the various Sun keynotes at JavaOne to see if I'm right. Best wishes, -- John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
