I'm a little bit surprised that the discussion turns to an argument about the benefits of an OO language. If this is seen as a major obstacle to the sexiness of the toolkit, maybe we can find someone to expose ACS Objects and CR Items to Java using ns_java or tclblend or other tools. Same goes for Python and Ruby. After all, we just need to be able to call a different languages procedures. Furthermore, due to the fact that some important parts of the functionality are hidden in the database, we don't have to care about the application layer language.
Therefore I think the easiest way to test if supporting OO will attract more users to OpenACS would be to make sure you expose the TCL API and the ACS Objects to Java and allow the Request Processor to serve pages written in Java along the ones we currently have in TCL. This allows anyone to use the existing functionalities while enabling her to write her own additional functionality in Java. This approach has the benefit of easier connectivity to proprietary third party tools, as they usually tend to come with a Java API.
Sadly I have no clue how much effort this would be and I guess unless someone really needs this for a client project or because of the need to finish a thesis we are not going to see much process.
