 |
Bloated Mustang?
Posted by opinali on June 22, 2005 at 08:34 AM | 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?
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
To be honest, I m still not clear why Rhino/Ecmascript was chosen to be integrated into the default JRE. The first problem I can see is explaining Javascript to people: "No, Javascript doesnt have anything to do with Java, actually its real name is Ecmascript. Well OK... its included in the default JRE... but still it... er..."
The best option would have been Beanshell, as it would allow to prototype Java code. Beanshell has the same syntax as Java (plus some relaxed rules ), and would make many things easier (prototyping, quickly finding out how some API, ...). This would allow to have Java on all levels: you get to use Java (the language) for playing with APIs/components, but you can move that code to your statically compiled classes. Wheras with Javascript... well, its a totally different model of programming. I dont like the argument that "Javascript" is syntactically close to Java... that's like saying that C is basically the same as Java... yes, both use curly braces but it's not like that matters... The object model of Javascript is different (prototypes vs. classes),...
Of course, over the next year, all or most of the Java based scripting langs (Jruby, Jython, Beanshell, .........) will probably get adapters for the javax.script anyway, so it won't really matter that much anyway;
This, in connection with increased usage of JMX will make Java more fun, as you can now just reach into the Java process and handle live objects...
Posted by: murphee on June 22, 2005 at 09:39 AM
-
While not a good reason for including Javascript in J2SE, I think that the interest in AJaX may make a good case for including Javascript in J2EE.
If folks start creating JSF components that generate client-side Javascript, they'll probably become much more amenable to server-side Javascript.
Just a thought...
--John
Posted by: johnreynolds on June 22, 2005 at 11:42 AM
-
A *lot* of developers out there already know JavaScript. Sure BeanShell might be easier (I personally disagree) but if you use the JavaScript engine in your application to add scripting abilities you're more likely to hit a broader audience. JavaScript is easy, well known and there are a lot of resources out there. It makes more sense for a user rather than using Python, Ruby or anything else.
Posted by: gfx on June 22, 2005 at 12:38 PM
-
John, in Ajax, javascript runs on the client-side, not the server-side. What's the benefit in including it to J2EE?
Posted by: ronaldtm on June 22, 2005 at 02:36 PM
-
John's probably meaning that it avoids learning Yet Another Language, on the assumption that as a large number of developers get interested in the "AJAX" stuff (not the cleaning product), they'll use JavaScript anyway.
I suppose once again that a lot of people are confused between JavaScript and the browser object model. Including Rhino is less bloat than might be imagined, as it does not include browser objects such as window, document, and so on. As such, Osvaldo's link to Mozilla's "evolutions" are misleading, as Mozilla will add extra objects to the browser DOM, but it's classed under "JavaScript" because that's the environment that will benefit from these new objects... It's not really JavaScript that's changing.
Rhino is a lightweight approach to scripting that adds things like closures and looser syntax for prototyping, although it'd be nice to have the improved "for" loop syntax, with only very basic overheads. It also includes E4X, a very simple way to integrate with XML documents.
For web developers, it gives an alternative language for server-side scripting and interactive prototyping, and for Swing/Webstart developers it enables you to provide VBA-like scripting in your applications without another download.
Posted by: chris_e_brown on June 23, 2005 at 02:13 AM
-
Chris: It seems you are correct on Javascript, and I shouldn't trust in Slashdot headlines like Mozilla Extending Javascript? without reading more about the subject...
Posted by: opinali on June 23, 2005 at 04:51 AM
-
Honestly, I still don't see the point to include JAX-WS.
That makes completly sense for J2EE but certainly not for J2SE (to me at least).
How many of you write desktop application dealing with WebServices ? If you are one of these guys, would you mind adding a JAR to your application (or a link to your WebStart) ?
For marketing purposes, that may sound cool ... but that will just give more work to the other teams building alternate implementations of a JVM.
Posted by: spetrucci on June 23, 2005 at 06:08 AM
-
The big picture is not lost on those complaining Mustang is too big and includes a lot of stuff it shouldn't.
SOAP, Web services, webservers, and stuff like that shouldn't be included in the core language, they should be optional addons.
The same goes for scripting languages.
What's next, include the full J2EE in J2SE because so many people use it? After all, we will now have a lot of duplicated functionality between the two so complete integration is logical isn't it?
And what about Groovy? That was supposed to be included as a standard feature as well at some point, would make yet another scripting language...
I wasn't too happy about some of the things added in Tiger, Mustang will be a lot worse.
Maybe my employer's plans to move away from Java after a 3 year experiment (during which I was taken on board as the resident Java guru) isn't such a bad idea.
Posted by: jwenting on June 23, 2005 at 06:08 AM
-
Concerning "why not Groovy?", I happen to know the current project manager, Guillaume Laforge, who got on board the project initially as an enthusiast. It's one of those (nowadays) rare Open-Source projects driven by real enthusiasts who want quality and real features. It's ambitious, yes, but that's the whole point. So it'll be ready when it's ready, and that's why there's slippage in the release schedules, and that's why it's not appropriate at this time as a choice for bundling with the platform, which does have corporate funding and deadlines.
Concerning the "bloat" around webservices, I personally don't use them, but remember, they're the "client" part of client/server applications, and hence need that infrastructure. It seems a perfectly valid approach to me, and is what Microsoft is using in it's client-server software stack. If you've been following "Indigo" development, you'll see this future trend continuing, so I'm happy that Java's anticipating this instead of playing catch-up when Java 7 ships...
Posted by: chris_e_brown on June 23, 2005 at 06:21 AM
-
Scripting provides a "Code Presentation Layer" since it is visible to the user (and their agencies).
Within a script, a population of objects can be instantiated, configured and linked (by creating/setting listeners and their actions {which can also be scripted actions}).
In the case of Applets where there are issues of trust and confidence this makes sense because there is now a presentation of the top level organisation of the system.
Since applets "intrude" into a users system they must be polite, open and honest, and demonstrate themselves to be so as far as is practicable.
This does introduce some new architectural considerations.
The key principle I suggest is that there can be MIGRATION of elements between script and hard-code, and back again.
At least by cutting and pasting and minimal modification.
A script sits in a different workflow from compiled code, one that users (or their agencies - consider a user in a company with competent administrators) will control.
From initial prototying of a system, through its deployment, and its life in the wild, this extends the possibilities that it can remain useful.
This clearly is not possible with just any scripting environment.
That is, it is not a bolt-on component but is an intimate part of a java system with a specific role, that of maximising the potential and utility of the hard-coded classes.
Posted by: tul_urte on June 23, 2005 at 06:45 AM
-
spetrucci, jwenting: I'm not a big user of WS either, but consider this additional argument in favor of bundling WS into J2SE. This is bundled in .NET's standard runtime (and Microsoft keeps adding WS stuff, see v2.0-beta). So at least for political / marketing / competitive reasons, the first-class support for WebServices is long overdue in J2SE.
Notice also that Mustang is not going to grow much bigger than this: the fatter additions have already landed. Other expected additions of any significant size are only JAXB2.0 and JSR268 (SmartCard I/O), and none of these are big. The other missing items are small updates to current APIs (such as JDBC4.0), standardization of stuff that's already bundled in Tiger (JSR199, JSR269), developer features that go in the SDK but not in the JRE (JSR199, JSR260, JSR269), and small VM/bytecode spec improvements (JSR202), unless something new is added to JSR270, which I don't consider very likely at this point in the process.
Considering the list above, Mustang is a pretty small update, I don't expect its JRE dowload size to be bigger enough (compared to 5.0's) to make people angry. In fact, while watching Mustang, I am much more excited about implementation improvements, like the recent enhancements in 2D and text rendering, or HotSpot optimizations e.g. escape analysis and new intrinsifications of math functions, or support for DTrace on Solaris 10+. And these have only a very small impact in JRE size (compared to new APIs). The SDK will grow more, but SDK size is irrelevant, for me the J2SDK could fill a whole DVD if Sun could produce this amount of new tools, demos and docs.
I'm sure you don't expect Java to stand frozen, and not add any feature in the 18-months period (at least) from Tiger to Mustang! Remember also that this new JRE will only be available one year from now, so a small increase in JRE size is more than compensated by the average increase of bandwidth... even in third-world countries like mine (Brazil), broadband is everywhere and the lowest speeds are as cheap as dial-up (but still much faster) after writing off modem price.
Posted by: opinali on June 23, 2005 at 08:07 AM
-
I really think that beanshell is a better option,
First the interpreter is small ~150K jar file.
Second, it is JAVA, it don't include a new syntax.
That is my point about javascript, it uses a different syntax, and I think that it is not a good idea adding 2 different syntaxis in the J2SE
Cheers
JD
Posted by: jdavi on June 23, 2005 at 09:18 AM
-
Maybe Mustang won't get much bigger (though after adding 2 or 3 massive and unnecessary (except indeed maybe politically) features nothings to stop them from adding a hundred small features which together are a lot bigger than those few combined.
Sun (and the JCP) should instead concentrate on getting rid of bloat, removing to optional packages things which aren't essential (and that in my opinion includes removing Swing and AWT!) and cleaning up 10 years of crud in the form of removing the hundreds or even thousands (I've no precise count) of deprecated classes and methods (and I mean removing, like culling from the codebase).
Java is trying to be out of the box a complete programming environment, trying to be C++ with a ton of optional libraries. This makes Java a lot harder to use and especially learn just at the time when Sun is campaigning to get more people to learn Java.
Posted by: jwenting on June 24, 2005 at 01:11 AM
-
J2SE and J2EE need to start putting their heads together to remove much of this redundancy. This includes scripting support (javax.el vs. javax.script). I mean, the features being added to J2SE probably serve the idea of supporting thin desktop applications (WS, HTTP, JS), but again, some of it should have been aligned with J2EE or put in separate libraries.
To go off on a tangent-- is more practical to keep the functional code base small within J2SE and J2EE and then provide separate, supplementary APIs for development? To mirror open source trends in an example, you don't see Apache packaging 'commons' or 'jakarta' as a single library for good reason.
Posted by: jhook on June 24, 2005 at 06:40 AM
-
jwenting: You mention deprecated APIs, but this just an "urban legend". The weight of all deprecated APIs in J2SE is so small that if Sun removed all of them, the reduction in JRE size would be microscopic, perhaps something like 1%. Not only the number of deprecated APIs is several orders of magnitude smaller than the non-deprecated ones, but also, most deprecated APIs have trivial implementations (like getters or constructors) or are implemented delegating to the newer APIs. So you would pay a huge price in compatibility for some 100Kb savings in download size... which is really nonsense.
Now, a different idea is dropping entire APIs that didn't resist very well to the test of time, and replace them by full-new APIs with a better design. A good example that everybody mentions is the whole lot of Date-related classes. But the problem of removing some class is that you must change every public API that depends on it. For example, I would love to get rid of the ancient collections (Vector, Hashtable, Enumeration, Stack) but these are used in return values and parameters of newer APIs like Swing. So you gotta break compatibility everywhere. I suppose we could eventually have a major overhaul of Java (Java3?) fixing everything that isn't fixed today for compatibility reasons, and provide an optional rt-compat.jar for older apps, or something like that. But even in this case, reduced JRE size wouldn't be a benefit, because the newer, better-designed APIs would certainly be at least as big as the dropped ones. When evolving a software platform, you can even drop the "form" of your APIs (type hierarchies, method signatures...) but you can never drop functionality; the newer versions have to do everything the older versions did, even if demanding some porting. It's just like operating systems -- what's the last version of Windows (or Linux, or...) that had a smaller number of features than previous version?
Posted by: opinali on June 24, 2005 at 07:57 AM
|
java.net RSS Feeds
