Skip to main content

An opinion on deliverables..... mainly the rhino implementation

7 replies [Last post]
caclark
Offline
Joined: 2005-02-24

Hi

I was concerned that the latest Rhino release was not fully realized because it involved certain features that a poster (A. Sundararajan's Weblog) said was not to be included....

"Although Mustang includes Rhino 1.6R1 (and probably will change to Rhino 1.6R2 before FCS), we are not including E4X (ECMAScript for XML) support in it. We had removed this feature primarily because of footprint consideration. Note that E4X Rhino implementation uses Apache XMLBeans (xbean.jar)."

please explain to me how this is a good scenario regarding scripting implementation in the next version of the java platform.... E4X is the only reason I personally would move to using Java 1.6 scripting (as it seems to currently be based on rhino).

I have 2 questions to Sun Microsystems Inc.

(1) javax.* was developed as a package prefix that was
meant to symbolise an adaption to the standard platform. Why are Java developers still subjected to 'full' deployments of the java platform which include these supposed amendments to the base libraries? Is there confusion now about what 'javax.*' means?

(2) Why cannot Sun deliver full Rhino specs? E4X is a very compelling reason to use client-side scripting regarding unit test functionality, especially regarding SOAP clients.

Regarding (2) I'm sure that Sun, in conjunction with the open source community, could put some effort into creating a sun/apache approved Mustang Rhino implementation (instead of giving up because they think that the download size would be increased too much... come on, Sun, you already forced asynchronous SOAP communication upon us and yet didn't explain anything about the possibility of setting up the HTTP server socket in the first place - what about java.net.HttpServerSocket?)

Regarding (1), why is it still a prerequisite to deploy J2SE implementations based on supposedly additional packages? javax.scripting is just the latest in the line of javax.* packages.

As far as I am concerned, java.* packages are the only true java packages I should consider final, or am I wrong?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kkrouse
Offline
Joined: 2005-12-01

Mustang with Rhino without E4X would be very sad indeed!

From what I remember when I looked at E4X, only XmlCursor and XmlObject are used from xbean.jar -- it may be possible to create a smaller xbean.jar. Or perhaps E4X could be rewritten so it used the DOM? Or something completely different?

alexlamsl
Offline
Joined: 2004-09-02

shall we file an issue in the Java Bug Parade and vote for it?

chris_e_brown
Offline
Joined: 2004-09-14

It seems to be madness to drop E4X XML language integration from bundled JavaScript in Java 6 and yet propose XML language integration for Java itself in Java 7!

This sort of convenience is better suited to scripting and not to the core language.

- Chris

caclark
Offline
Joined: 2005-02-24

Thx for the feedback - my issue about pluggability (the javax.* packages) was not really to do with download size, mainly to do with the original concept of javax packages, in which they were supposed to be extensions to the core of the JDK... so being able to add/remove them at will should not be an issue.

Regarding the Rhino E4X additions, it does seem to me that the Rhino implementation was built for a specific release of Java (maybe for backwards compatibility). Would it not be more sensible to say... if we are providing a Rhino implementation for the javax.scripting API, why don't we make it JDK 1.6+ compatible (i.e. remove all the internal code for backwards compatibility, and use the wealth of APIs available in Mustang to cut down the size of the Rhino implementation). That is one option, and could cut down substantially (for one example), the XML beans package size.

alexlamsl, I agree with your comment (thx for the research snippet) - pack2000 does significantly reduce the download size, and a 2.5% increase shouldn't be a big deal.

and yes, I also find E4X a compelling reason to use Rhino :-)

I will be interested to see how the politics proceed regarding Mustang and Rhino - if the final release of Mustang *still* has this cut back implementation of Rhino, I can imagine a lot of people downloading Rhino themselves and using it to Mustang to make up for the functionality losses (bloating the installation further). This sort of behaviour has happened before with the JDK CORBA implementation (mainly due to the bizarre API though, with the ORB singleton).

Chris

chris_e_brown
Offline
Joined: 2004-09-14

Oh dear, this seems like a fork..!

I'd prefer either bundling it all (with optimum compression) or not at all, otherwise there'll be fun classloader/packaging issues with those, like myself, who find E4X a compelling reason to use Rhino.

- Chris

alexlamsl
Offline
Joined: 2004-09-02

Right I have done some experiments with xbean.jar (from XML Beans release 2.1.0)

xbean.jar - 2,637,744 bytes
xbean.pack.gz - 427,159 bytes

So it's going to add less than half a MB to the JRE distribution. With the current Tiger JRE (JRE 5 Update 5) - which is 15.67MB for the offline installation version - this would increase the download size thus time by just over 2.5%

I must say that I now stand on your side, caclark - even if someone has to download the whole offline JRE in say one hour, bundling xbean.pack.gz will only add another minute and a half to the download time! Exactly how much of a foot-print increase are we worrying about here?

alexlamsl
Offline
Joined: 2004-09-02

To part of the community which network connection speed is a major bottle-neck for everything (not me though ;) ), size of the JRE would be a major concern. (or so I hear them complain around here every now and then)

Even without E4X though, Scripting (esp JavaScript) support in Mustang is going to be unquestionably useful to many; the possibility of using [b]eval()[/b] in many cases - instead of bundling the whole JDK / create your own DSL and so on - is already presenting a very bright future to me :)

Now onto E4X - which I admit is a useful feature as well - if the Rhino team can bundle it as a convenient add-on JAR then it should be a good enough solution for now; "bundling" it with your application via JNLP should be as easy as cheese (it is supposed to be, at least)