Yes, I'm here... Well at least I try to follow the bboard discussions every day. I've been quite busy lately, and I haven't had much free time for opensource projects in general, so I haven't devoted any effort to ns_java/ns_javablend in quite a while. Couple that with the fact that there never has been much interest in the community for ns_java, and you can see why there hasn't been any development on it in the past year.
Staying away from TclList is not a viable option, since it's used through ns_javablend at the lower levels. The memory leaks can be quite extensive on a busy site such that you would need to restart the server frequently. Running a production site using ns_javablend is just not a good option right now.
If I do get back to a point where I have more free time, I think I will rewrite ns_javablend so that it doesn't depend on Tclblend. Tclblend duplicates the workings of a tcl interpreter in java, and it's quite a complicated process to keep everything lined up between the tcl and java sides of the process. As a first step, I've created a new object model for the java objects, and I've written a tcl object-oriented extension module to test out my ideas for simplification of ns_javablend. There is alot I want to do, but as I said, I just don't have the time.
The limitation is not really a limitation in the context of aolserver, since you normally only have one interpreter per thread anyway. I'm not even sure that you can create a new interpreter once a thread is started when using aolserver. The limitation is just stating that you can't do:
interp create
from within a tcl script when you're using ns_javablend.
