JavaScript already is running in a JIT-enabled VM with the same bells and whistles managed code developers are used to. What it doesn't have is type safety, so you can effectively think of JavaScript as your medium of distribution -- bytecode. It just happens to be human readable, so a lot of people write it by hand. But you can just as easily have a tool that "compiles" your strongly typed language into JavaScript, package it for distribution with some limited compile-time optimizations and rely on the client-side VM to do the rest. This is exactly what GWT does.
Alexey ________________________________ From: Carl Jokl <carl.j...@gmail.com> To: The Java Posse <javaposse@googlegroups.com> Sent: Fri, November 5, 2010 6:16:13 AM Subject: [The Java Posse] Re: Evolution from web to desktop? I hope it may be a good sign that others are thinking on the same lines as I have been thinking too for some time. Albeit I am not sure if it will happen. Considering Flash, Java and .Net amongst others all have some kind of Virtual Machine. It would be good it the "JavaScript" engine were a virtual machine too supporting some kind of bytecode. This means that it could be targeted by any compiler which could compile to that bytecode. In terms of supporting all the languages. Support for the languages may not be so much of the issue. It is really a matter of the API's. Saying that something cannot be called Java because it doesn't support the whole JavaSE API set may not be a fair statement. We already have had JavaME which is branded as "Java" but only supports a much more limited set of APIs which are suited to that platform. In that case would it not be reasonable then to have a JavaWE (Web Edition) or JavaBE (Browser Edition), such that the APIs are limited to just those which are supported currently by JavaScript. Needless to say JavaScript doesn't support anything like the rich functionality that Java or .Net do but surely you have to start somewhere. If broad support for the browser VM came into place then expanding the functionality could be done bit by bit via the W3C. In the case of things like Flash, JavaFX and Silverlight it may be that the functionality needed for those could be provided by loading additional libraries beyond the core "Browser JM Libraries" to provide that functionality. The aspect that could make it interesting is the prospect of seamlessly pass objects from server to client back to server the way thick clients have been able to such as with RMI, RPC, CORBA etc. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
