Osvaldo Pinali Doederlein's Blog: June 2005 Archive

Posted by opinali on June 22, 2005 at 08:34 AM | Permalink | Comments (15)

Build 40 of Mustang was the first drop with the first significant new API additions. And the inevitable happened as some people started to complain about the addition of "useless" features: who needs Web Services, Javascript or an HTTP server? Why Javascript instead of [put favorite language here]? Some of these features are indeed hard to justify in J2SE, if we miss the big picture.

The first (and the biggest) new API is JAX-WS. The trend of Web Services has definitely chilled out from the overhyping of a few years ago; people are not anymore planning to replace robust and efficient middleware by SOAP without really good reasons. Nevertheless, WS are very important, and interoperability was always one hallmark of the Java platform. Some people even wanted to see basic WS APIs in Tiger, but it was too early by then. Now the WS-I specs are more complete and firmly settled, the implementations of WS-I-compatible runtimes are much better than early 2004. So it was not a surprise for me that fewer people complained about this addition to the core, even though it's the bigger piece of the cake. This bundling is also important for performance reasons. The APIs for XML, SOAP and related technologies are very critical and they can benefit from important features of newer J2SE releases, from java.nio to StringBuilder to java.util.concurrent to whatever comes in Mustang. But non-core APIs (like those in the JWSDP) usually have to keep compatibility with older J2SEs. So let's put at least all critical pieces of XML and WS in the core and optimize them to the max, because the pressure keeps coming.

Let's see the HTML serving feature. I'm frankly appalled with some people who complained about this, without making any connection to the Web Services APIs. Hey folks: SOAP (and the whole WS stack) requires this. And no, Sun didn't include a full Servlet/JSP/WAR container in Mustang. It's only the most basic HTTP protocol service capability, and I don't expect this to be very fat. Alas, I couldn't seem to find this HTTP serving feature in public APIs, so I guess this is internal to the WS packages but I hope it's going to be exposed by some public API... it costs nothing since the implementation is already there, people may want to listen HTTP for some non-SOAP needs, and it's a nice counterpart to the current HTTP capabilities of the java.net package.

Now let's talk about scripting. Many people like scripting languages, but choosing a specific language is a heated debate. Personally, I don't like these languages; I hate when I have to hack some Javascript (inevitable in Web GUIs) and that's just how far I go with scripting. I am a firm believer in static type checking and other "bureaucratic" features of conventional languages. On the other hand, I'm keen on higher-level language features like closures, purer typesystems, or language-level support for several tasks (collections, markup languages, SQL etc.). Many scripting languages deliver these features. I like what I've seen of Groovy because it's a higher-level Java that I'd enjoy to use in some situations – when I don't need the extra performance of Java's lower-level designs like more static dispatch and primitive types. But I couldn't care less about the scripting side of the language: if they drop the interpreter option or "eval" capabilities, I'll be missing nothing.

Having presented myself as an independent and unbiased judge (not a fan of any of the competing languages), I think Javascript is a good choice if any such language is to be embedded in the J2SE. Javascript may not be the best scripting language available, either in design or features, but it's not bad as a pragmatic choice. Javascript is

Very popular. Most developers know it already. Billions of browsers out there support it.
Mature and stable for several years (although it's apparently evolving again).
Formally standardized by multiple ECMA specs.
Familiar to Java programmers, with virtually the same syntax.
Very small. Its runtime adds 660Kb (uncompressed) to Mustang.

It is very difficult for any other scripting language to compete with the list above. BeanShell and Pnuts are not popular enough, and as programming languages they don't add anything, only relaxed syntax. Groovy is not even at v1.0, and programming languages are slow to mature. Even if Groovy reached a nice FCS in time for Mustang, I'm 100% against the inclusion of any full-new language in the J2SE. The core Java platform must hold very high standards for stability and compatibility, and you really don't want the integration of a language that's still in a stage of fast evolution, trust me. Languages like Ruby and Python are cool and mature, but their pure Java ports are lagging a lot behind the latest reference implementations. And those more "respectable" languages are bigger – exactly because they are mature languages that try to be useful on their own, so they need a standard library of APIs of reasonable size, and it's these libraries that make the languages big. There is no competition to Javascript, because Javascript doesn't need any APIs – it was designed to piggyback on interfaces exposed by web browsers, like the DOM tree, which serve as the API for scripts living in HTML pages, but are irrelevant outside a browser. This explains why a complete Javascript runtime fits in little over half megabyte. Even Groovy, which is designed to depend on the J2SE APIs, is several times bigger (even after you cut all redundant stuff, like XML parsers and other things that are/will be already bundled by the J2SE).

Not that I am completely happy with Javascript either. For one thing, I think Javascript should be updated with some new goodies of JSR-201 like enhanced-for and varargs. Otherwise, it will be funny that a scripting language may be often more verbose and less productive than its more conventional counterpart, Java.

The real question here is whether we should have any scripting language included in the J2SE. The JSR-223 abstract package, javax.script, is small (~26Kb), but I always wonder if it's a good idea to put in the core an API without a concrete implementation. It smells to vaporware, and slows the adoption of the new API significantly. A good case against bundling is when you can't have a single RI that works for everybody, e.g. for JDBC drivers (and even in that case, there is the bundled JdbcOdbc driver!). In the domain of scripting languages, you can have an implementation that works in all environments, but different users want completely different languages. Well, I don't really know what is the best option here.

I guess that this bundling of Rhino would be more firmly justified if it was useful to other J2SE 6.0 features. Mustang is planned to have some sort of shell utility based on JSR201, that will be great for quick exploration, and integrate with the J2SE's growing serviceability features. This is a great dog-feeding of JSR201 and it demands the bundling of a concrete scripting implementation; but it's a developer-side feature that could be well served by bundling in the J2SDK's tool.jar. Another interesting use of Rhino is found in Cocoon, where Javascript's support for continuations makes possible a programming model that may well be the next big thing in web frameworks. Truly cool stuff, but not a case for J2SE bundling either, since it would be good enough to include Rhino in J2EE 6.0 and future versions of Servlets / JSP / JSF / whatever. We're still missing a killer app for scripting in the JRE. One idea: Swing's aging HTML component might become capable of DHTML behaviors (I'm not much of a client-side developer and I don't know how cool is this idea, perhaps it's good for JavaHelp?). Any other ideas?

Powered by
Movable Type 3.01D

java.net RSS Feeds