Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New Rhino maintainer announcement + road ahead + call for volunteers

3 views
Skip to first unread message

Attila Szegedi

unread,
May 18, 2006, 11:26:05 AM5/18/06
to dev-tech-...@lists.mozilla.org
Hi all,

Igor Bukanov stepped down as the module owner for Rhino since he currently
doesn't have an interest in it. At the same time, he asked me if I would
take over as the new maintainer. After thinking about it for some time, I
accepted the responsibility. (The http://www.mozilla.org/

I'd like to outline what does this change mean for Rhino.

First and foremost, I must say that I'm far from being an ideal project
maintainer. An ideal project maintainer has heaps of time to devote to the
project, and knows its ins and outs.

Now, I'm neither.

First, the time. Rhino is in enoromously widespread use, in uncountable
number of web applications, server side scripting, GUI scripting, etc
solutions. It is even bundled as the default scripting engine in the JDK
6.0. It is a real honour to be offered to steer this project, and I'm
taking it very seriously. Regardless, the time windows I can dedicate to
Rhino are those that don't overlap with my paid work time, and that only
partially overlap with the time I need to devote to my family, and that
don't impair my rest time significantly so that I can still provide
adequate quality work to the people who pay my bills during weekdays.
These I also all take very seriously. In plain English, Rhino gets hours
out of my weekends, and sometimes maybe parts of my evenings as well.

Second, the knowledge. I've been through the (user -> patch contributor ->
committer) evolution chain. I know the Rhino source code rather well, but
far from perfect. There are white areas (good knowledge), gray areas (used
but not dissected too much -- i.e. Interpreter class), and black areas
(never used, never looked at -- bytecode compiler, E4X). My ability to
patch or to evaluate correctness of patches in grey/black areas is
somewhat limited, although I promise to do my best to understand the code
involved with a patch, if you submit one. We might go through few rounds
of questions and answers though when you submit a patch, be prepared for
that. I'm almost 100% likely to be unable to provide patches myself for
these components if you can not provide a patch yourself but just report
the bug - again, I'm talking primarily about the stackless interpreter,
the bytecode compilation, and the E4X support.

So, this is the new maintainer you got :-) On the bright side, Norris Boyd
reassured me he's willing to occasionally help out, and I believe that
neither Igor nor Brendan will mind if I bug them occasionally if I get
stuck on something.

Let's take a look at where's the project today, and where do I think it
should be headed.

On the bright side, we have a widely used codebase that runs with not too
many issues. On the dark side, we have those "not too many" issues. A
brief scan of Bugzilla shows 54 open issues, 22 of which are E4X related.

This brings me to the two major things I'd like to see in the Rhino's
future:

1. Reimplementation of E4X without relying on external libraries, but only
on SAX and DOM support present in javax.xml.* packages. Apache XBeans,
used as the foundation for the current E4X implementation, suffers from a
rather bad codebase -- there are gratituous object poolings in there that
are good mainly for causing memory leaks etc. Without external
dependencies, E4X support would likely be includeable in the JDK-bundled
Rhino as well (Sun won't include it in the Rhino version they endorsed for
6.0). I'm not saying that all E4X bugs stem from XBeans, but I'm saying
that the current E4X implementation has lots of problems, and that I'd
most gladly see a fresh start on it. There's just one gotcha: while I'd
like to provide a very loose high-level architectural consultancy role for
it, I definitely don't have the resources to go down in the trenches and
code it myself. So this is also a CALL FOR VOLUNTEERS who feel they could
give the world a better E4X support in Rhino.

2. Abandoning JDK 1.1 support. There's lots of JDK 1.2+ specific
functionality in Rhino that has to be implemented using all kinds of
reflection workarounds, so as to allow Rhino codebase to both compile on a
Java 1.1 platform and also execute on it. The resulting code is
necessarily, to say the least, rather inelegant and poorly maintainable.
Then there's functionality, like ClassCache, that's implemented using a
Hashtable for 1.1 compatibility, where in reality it'd have to be
implemented using a WeakHashMap so that it doesn't interfere with
unloading of classes, but weak references are a JDK 1.2 feature. Also,
JavaAdapter could be rephrased in terms of java.lang.reflect.Proxy. I view
1.1 support to be a burden without a comparably big benefit for further
development, and barring a *big* public outcry in response to this
announcement, I intend to move the development forward without much regard
for it. I think that targetting a minimum of JDK 1.3 compliance is a
realistic expectation in 2006. The next bugfix release of Rhino, 1.6R3
will however definitely still preserve 1.1 compliance.

As for "less major" (but not really minor) things:

1. We'll soon include a scripting provider service declaration in the
META-INF of the js.jar so that the JDK 6.0 bundled Rhino can be
transparently replaced with our standalone Rhino implementation for
running *.js files by simply including js.jar in the classpath.

2. Next release. I've started going through the bug tracker last weekend.
I'll continue this work this weekend. When I get to the bottom of the list
having addressed everything that I could in it (which most likely won't
include any of the 22 E4X issues, unfortunately), I intend to publish the
result as Rhino 1.6R3.

So, that's it. Any and all input on any thoughts expressed above is more
than welcome.

Attila Szegedi,
your new Rhino man-to-blame.

Cameron McCormack

unread,
May 19, 2006, 1:47:23 AM5/19/06
to
Hi Atilla.

Attila Szegedi wrote:
> Igor Bukanov stepped down as the module owner for Rhino since he currently
> doesn't have an interest in it. At the same time, he asked me if I would
> take over as the new maintainer. After thinking about it for some time, I
> accepted the responsibility.

That's great news!

> So, that's it. Any and all input on any thoughts expressed above is more
> than welcome.

As long as you get to my bug/patch[1] at some stage I'll be happy. :-)
I'd like for the next Batik release to use a non-patched Rhino release.
The next Batik release won't be for a while, though, so no hurry.

Thanks,

Cameron

--
Cameron McCormack ICQ: 26955922
cam (at) mcc.id.au MSN: cam (at) mcc.id.au
http://mcc.id.au/ JBR: heycam (at) jabber.org

Merten Schumann

unread,
May 19, 2006, 2:32:28 AM5/19/06
to Attila Szegedi, dev-tech-...@lists.mozilla.org, Igor Bukanov
Hi Attila,

first, I'm sad to hear that Igor and Rhino now live apart in a way ...
I remember him very well, back in 2004 he provided me with a lot of
helpful hints, fixed some issues very quick and even added some
functionality "for me" to Rhino.

Anyway, very good to hear that there's someone taking over the
responsibility for the Rhino code base, Good luck, Attila! :-)

cu
Merten

David P. Caldwell

unread,
May 21, 2006, 7:55:49 PM5/21/06
to
Attila:

I've just started using Rhino in the last couple of months, and I've
wondered about project direction. It's really exciting that you're
working to help set/develop one. So, enough flattery -- on to the
details. :)

First, your "major" points:

As for #1, I may be able to help "give the world a better E4X support
in Rhino," slowly. I've been hacking around just a little bit to fix
showstopper E4X bugs in my local copy of Rhino. I can take a more
comprehensive look through it. I've thus far been pursuing a patching
strategy, so I'm really not analyzing where the XMLBeans dependencies
are, and thus I do not know how much work it would entail to replace
them. I agree that replacing them would be ideal -- someone
contributing to the project ought not have to learn the XMLBeans API,
for example, and distribution-wise it's cumbersome (and the
documentation mentioning the dependency was wrong, as I recall --
specifies only xbean.jar and not the jsr173_1.0_api.jar). But removing
XMLBeans calls has not been the strategy I've pursued thus far, and I
intend to continue with patching for the moment (fixing some of the
bugs has been very simple, and others might be).

I decided to start by running the e4x test library on Rhino 1.6R2,
which produces a horrifying number of errors (59 failures in 187 tests,
including several that I aborted because they appear to enter infinite
loops). But I can say that I've been able to use even the existing E4X
support productively, albeit with some-to-much working-around. I've
only run into a few of the bugs, none that I would rate critical. The
one that's been most difficult to work around is 320812, and the most
embarrassing is 290715 (I think I have a local fix for this).

As for #2, I see no reason to continue JDK 1.1 support. I don't know
of anyone using JDK 1.1 anywhere, myself.

I don't have anything to add on the "less major" points for the moment,
except that it's not clear when you think R3 might be, but it's
unlikely I'll make my way through much of the E4X backlog before it
happens, unless it's going to take you a while to get through Bugzilla.

Back to work,

-- David.

0 new messages