More things to do - a new Java view

[Steve Poole <sp...@googlemail.com>]

I was thinking about what we should write in the way of demos to help with
the education Stuart is doing at ApacheCon.

I favour producing a demo thats visually interesting , useful (of course)
and relevent to other Apache projects.

I like the JDI connector we've done as it is useful and interesting and is
presented in a way that is already understood by the consumers -  ie we all
know how to navigate a Java debugger.

So with those thoughts in mind I was looking at writing a demo that provided
information about an Apache Tomcat server -  things like loaded
applications,  servlet state etc
The Tomcat manager has a few jsp pages that we could copy and create similar
reports - but with the data coming from a dump.

However - once I started playing around with the idea I ran in to some
usability issues with Kato.   For instance to build one of the demos I need
to get a list of all the instances of a specific interface.  That is
complicated though, since Kato only specs the interfaces that a class
directly implements -  not what it inherits.    To get the data I need to
progress means I have to build a set of helpers on top of the API.

I also want to exclude unreachable objects - going to the heap is not
correct since I can pick up unreachable objects.   I'm going to have to do
my own gc sweep to get the live objects.


None of this is really remarkable;  since the API  was originally targeted
at  JVM developers the API is designed to show what is real from a JVM point
of view.    Now we are moving towards a mainstream audience we need to look
at how we provide a Java Application programmer centric view.   I had
mentioned this idea at the start of the project as a possible addition to
the API -  Now I think we need to do it.

My proposal is that we build a new view on top of the JavaRuntime  (name to
be decided)   That hides the JVM internals and embededs a lot of helper
functions.   Its not completely trivial  but it does have a lot of
benefits.    My thought is that if we don't do this as a properly structured
API we're going to end up writing it piecemeal anyway as a whole series of
helper functions.

Thoughts?