Bloated Mustang?
Posted by opinali on June 22, 2005 at 8:34 AM PDT
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
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
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
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
again). - Formally standardized by multiple
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
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
language included in the J2SE. The
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
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
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?
Related Topics >>
Blog Links >>
- Login or register to post comments
- Printer-friendly version
- opinali's blog
- 1175 reads
