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.