Sun turns Javascript into Java. Google turns Java into Javascript.

Sun turns Javascript into Java. Google turns Java into Javascript.

Summary: Yesterday, in my treatise about why Sun's emphasis on R&D and developer communities is too easily dismissed, I slipped in a bit of news about a skunkworks project at Sun called Phobos that the company unveiled this week at JavaOne.  In the bigger scheme of things, Phobos is about how developers that work in languages other than Java will be able to program a Java Runtime Environment (JRE) with those non-Java languages.

SHARE:
TOPICS: Open Source
10

Yesterday, in my treatise about why Sun's emphasis on R&D and developer communities is too easily dismissed, I slipped in a bit of news about a skunkworks project at Sun called Phobos that the company unveiled this week at JavaOne.  In the bigger scheme of things, Phobos is about how developers that work in languages other than Java will be able to program a Java Runtime Environment (JRE) with those non-Java languages.  This pick your favorite language for scripting runtimes is called "dynamic language support" and it has long been a feature of Microsoft's .Net runtime environment. 

This has been a subject that's near and dear to Sun director of Web technologies Tim Bray's heart as evidenced by the Dynamic Java summit on the subject that he held on Sun's Menlo Park campus some 18 months ago.  In the time since that summit, languages other than the ones that were represented there (Perl, Python, Parrot, and Groovy) have been taking off or experiencing a ressurection of sorts.  Namely the uptake in Ruby, PHP, and Javascript (under the auspices of a technique known as AJAX) are generating considerably more interest on Sun's behalf in dyamic language support the Java platform.

So, in the big picture, Phobos, which is about scripting server side Java with Javascript is very much about the company's willingness to move to more of a dynamic language model.  In the small picture, it's about Javascript developers who prefer to work with one language when developing applications that require scripting on both the client-side (where Javascript is already the preferred scripting tool) and the server side where Javascript, as a programming platform has been dead for years.  So, is Phobos really Server-side Javascript: The Sequel?  With server-side code typically not involving a browser where AJAX really sings, will someone with a twisted mind figure out a reason to do server-side AJAX and run a JRE with it?

But wait, there's more.  Just when you thought that Java and Javascript had nothing to do with each other, and then, suddenly, thanks to Sun, now they do, Google comes along and does almost the same thing, but in reverse.  Although I missed the announcement at JavaOne, I had a chance to interview Google Developer Programs product manager Brett Taylor today to get the details.  Said Taylor in the phone interview:

On Wednesday, we launched the Google Web ToolKit (GWT).  It's a Java software framework for developing AJAX applications.  With it, you can write your applications in Java, and use the Google Web Toolkit Compiler to convert that code into browser-compliant Javascript and HTML. With the Web Took Kit, Java developers can use the development tools that they're used to using and they can write an entire application without ever using Javascript?

So, whereas Sun's Phobos allows developers to run the Java platform with Javascript, Google's Web TookKit allows developers to run the Javascript platform with Java.  What were Google's motivations?  Not too different from Sun's.  In supporting Javascript on the server side, Sun saw the convenience of giving developers programmable access to both ends of the pipe with one language. Plus, giving Javascript and AJAX programmers access to the Java Runtime Environment is a way of exposing the functionality of the JRE to a new class of programmers.

According to Google's Taylor, Google picked Java because a lot of Java developers are focused on Web development (Google's obvious sweet spot) and don't spend much time with Javascript.  By giving Java developers access to the Javascript environment without having to code Javascript, Google can more easily expose the functionality of its APIs to an entire class of developers that might not otherwise think about using them.  Said Taylor during the interview:

The way Java supports static type checking and modularity is really important for larger projects and that's where AJAX development suffered. It hurt the development cycle to not have a more strongly typed language. So, this is targeted towards ascale of application where it's particulary difficult to use Javascript.

Taylor said the Google Web ToolKit is also IDE agnostic.  The advantage, according to Taylor, is that Java developers can use their favorite tools to develop and debug the application.  In other words, they can do everything they'd normally do as if the app were being developed in Java and when they're pretty sure they've got it working, then they can compile it to Javascript.  To facilitate debugging, the Google Web ToolKit ships involves two modes: the Web debuingging mode and a production mode (or deployment mode). In the  debugging mode, Taylor says, you can run the AJAX application right in the Java Virtual Machine:

Normally with AJAX, when you click a button or link, a Javascript handler is invoked to handle that event. For the debugging mode, we ship with a browser so that when you click on that button or link, it invokes the Java event handler instead.  So, when you're debugging, you can uuse all of your tools like Eclipse to debug it, and then, when your ready to  deploy, you switch to the production mode.

One note however for the many Java developers building behind the firewall applications: According to Taylor, the Google Web ToolKit does not lift the licensing barrier that currently prevents Google's APIs from being incorporating into applications that aren't exposed to the public Web.  To officially get programmatic access to some of Google's functionality for behind the firewall applications, Taylor said businesses must look into acquiring one of Google's search appliances

In terms of some of the neat things that Google Web Tool Kit does under hood, one of them is that it automatically resolves browser dependencies which is good.  Java programmers are used to writing their code to certifiably Java-compliant runtimes which means they don't have to worry about code that will run in one place and not the other.  Thrusting them into an environment of target uncertainty is not something most Java programmers would appreciate from a productivity point of view.  Google Web Took Kit ameliorates the headaches of having to maintain separate chunks of code for each browser and the subsequent branching logic the developers typically must install to get their code working smoothly across all Web browers (perhaps a good reason for AJAX developers to become Java developers!).

Another neat trick of the Took Kit's is how it optimizes the code to keep the overhead and execution time down.  To the extent that it handles translation from one language to another, the Tool Kit is pretty much middleware and middleware, as Java developers well know, typically involves a performance hit in order to consistently get the translations right.  So, the potential for a large piece of Java code to generate and even larger chunk of Javascript is pretty good. To optimize the code, the Took Kit first analyzes the Java code, then it eliminates any Java classes or methods that weren't explicitly used in the code, and then it compiles it into Javascript.  But, when consider how some hardcore Java applications can end up being rather sizeable, Taylor admitted that "there is obviously a limit and that's going to be a practical issue for very large applications."   

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

10 comments
Log in or register to join the discussion
  • ASP has done this for YEARS

    Hooray. Now I can use "the COBOL of Web development" (to quote Roger Ramjet) to code on the backend. Let me call my lawyer, because I can see some stress related mental health problems if my boss every asks me to actually do this. ASP allowed people to do this for something like forever now. No one did it. When given a choice, no one programs in JavaScript. I have never heard of anyone chooising JavaScript over any other language. The only reason to use it is when it is the only game in town, like on the client side of HTTP. There is a reason why you don't see JavaScript anywhere else. It stinks.

    J.Ja
    Justin James
    • JSP has had it for years too

      JSP can do scripting languages also, and has had the capability for years. There is a vast array of Java based scripting languages. Groovy, Beanshell, and JRuby to name just a few. Javascript has been there for years with Rhino.

      But interestingly enough, Phobos seems to lack in depth. It only covers server side like ASP. What the heck? Ruby on Rails is not just about server side scripting! See Prototype for an example. It is a two way street. Projects like haXe, which compiles a simple scripting code to both server and client side (at the same time) seems a better alternative to either ASP or Phobos idea.

      And I also agree that Javascript sucks. No sane person would want to code in that horrid scripting language!
      OhMyGosh
    • There is a reason why there is the word script in Javascript

      > I have never heard of anyone chooising JavaScript over any other language

      Javascript is a "scripting" language (hence the word "script" in it) - there are different types of developers out there - a lot of them are not even using scripting languages at all - Javascript is still being used strongly as of today (mostly client side I reckon) - if it sucked that much, I wonder why there are so many cool, useful and powerful GreaseMonkey JS scripts developed and continue being developed out there...Javascript has not been really present on the server side but now that other scripting languages are making their way to it, why not Javascript - it has a close integration with Java (especially with the Rhino engine) and it's one more choice - you you stucked? no...

      > ASP allowed people to do this for something like forever now. No one did it.

      ASP tight integration with Unix or other non-MS OS'es? Yeah right - VBScript and VB, oh yeah, very much Object-Oriented languages, I think not...VBScript was considered to be one of the weakest scripting language out there (poor design and (object) limitations)

      > There is a reason why you don't see JavaScript anywhere else. It stinks.

      Again, Javascript is a scripting language and is usually mostly used on the client-side of web apps, and you usually find Java and/or other languages in other tiers...Saying that it stinks is as cheap as saying it does not...I don't think it does, but again I have only been developing for 18 years...

      by the way, Cobol is/was not a scripting language (scripting and non-scripting languages have different semantics) - Javascript has been in development for 14 years ago, ruby 13 and Python 15...

      Francois Orsini
      forsini
    • Client side makes more sense

      I don't get the idea of translating server-side Javascript into Java. As has been noted, there's already nice integration between Javascript and Java. A friend of mine had a job working on server-side Javascript some years back. He didn't like it one bit. The main reason being its dynamic typing. He didn't do any Java integration though. He preferred server-side Java.

      I haven't tried them yet, but apparently there are Javascript debuggers out there. So at least there's that.

      I've done some Javascript on the client side. Little things like alert boxes. In one project recently I did some DHTML. It's been alright, mainly because what I've been doing with it has been pretty simple. I wish I had looked for client-side Javascript debuggers though. Trying to debug client Javascript without one is not fun. It took me back to the days when I used to use printf() in C code to figure out what was going wrong.

      Someone else made a comment about VBScript. I asked a former coworker a couple years ago about it. He had a good amount of ASP development experience. He said even though you can use VBScript on the client, everybody pretty much just uses it where needed on the server. Javascript is what's used on the client.

      I think Google's approach makes a lot of sense. Give programmers an environment they're familiar with and has good tool support, and then translate it into something a browser can understand: Javascript. That way programmers won't need to deal with Javascript most of the time. They can just work in Java, and just have Javascript be like object code. It sounds similar in concept to "Atlas" in .Net 2.0.
      Mark Miller
  • how can we forget good ol' MS

    MS turns everything into C# and the .Net framework! lol!
    riv3rdal3
  • Java and Javascript have a lot to do with each other

    I beg to differ but Java and Javascript have been quite tight at the language and integration level for many years - you may not remember LiveConnect (originally from Netscape), still available as part of Sun's Java plug-in, which allows Java and Javascript to be tightly bound with eachother...such as being able to call Java transparently from Javascript and vice-versa at a language level...

    Now on the server-side, Folks have to realize that there are many (server) applications out there running in Java, and thus it does make sense to add scripting capabilities (i.e. Javascript) - does anyone need a "dynamic" scripting language (i.e. Ruby)? the answer is simple and is NO for most applications out there.

    Do people are familiar with Javascript? well, all I have to say is that it is currently used my most of web applications out there - this is not fiction - this is reality and has been for years.

    Why not on the server side? yes, why not - again it is is very well integrated with Java (which runs lots of servers out there), and can be converted into byte-code...

    You get a choice after all - if you want to capitalize on Java (existing apps or not) and you want to introduce a Java-like scripting to web developers, why not. It is true the other way around, as LiveConnect offered it years ago.

    Now, does that mean you're being locked into using this approach, the answer is NO. I see it as reviving Javascript on the server-side but in a better way than it was done years ago. Again, at the end you have a choice...Other (dynamic) language, such as Groovy/Grails integrates very tightly with Java and offer you dynamic language semantics you may require as part of your development/project...

    Francois Orsini
    forsini
  • firecat server-side JavaScript Webserver

    Firecat uses server-side JavaScript(NSP) as the main scripting language. So does a number of other webservers. I must say it is pretty refreshing to be able to use JavaScript on both the Client-Side and Server-Side. JavaScript has its place, if you use it properly. And I expect its usage will grow once Server-Side JavaScript comes of age.

    David Fu.
    firecat.nihonsoft.org
    fchoong
    • Firecat looks interesting

      The only problem I have is that while I use linux ([k]ubuntu), I program in windows... Firecat looks really interesting, but I can't really explore it very deeply yet.
      shryko
  • Google Web Toolkit

    It's lot easier working in Java than in JavaScript! The availability of Java IDE and since most of the Java Developers are habitual of working on them makes a Java-to-JS environment even beter!
    Also not having to create different JS code for different browsers in case of AJAX is really great.
    AbhishekAsthana
  • RE: Sun turns Javascript into Java. Google turns Java into Javascript.

    This article is very interesting. Thank you very much for sharing .
    <a href="http://www.flvdvdconverter.net"><b>FLV to dvd Converter</b></a>
    dkoi