Hi Steve,
I think the first option would be ideal of course. But I assume the initiative to develop
RI based on Sun's Serviceability Agent (which would lower the implementation cost dramatically)
has failed because of GPL-related issues. I wish there was a volunteer from the open-source
who could adapt SA to the KATO API...
>From the other two, the second one (remove Image API) IMO would very much discord with
the original message of the JSR (*postmortem* analysis, which means digging through the core
dumps). So I'd vote for leaving as much as possible of the Image API in the spec, making parts
optional as needed.
Thanks,
Konst
Intel Novosibirsk
Closed Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation
>-----Original Message-----
>From: Steve Poole [mailto:spoole167@googlemail.com]
>Sent: Wednesday, November 25, 2009 7:44 PM
>To: kato-spec@incubator.apache.org
>Subject: Do we need to change the scope of the API design?
>
>Stuart's note on diagnosing JNI problems (thanks for the review Stuart) has
>touched on a key point concerning what we want to do and what we can do.
>
>I think its time we discuss where we are and what happens next.
>
>Our desire to specify an API that helps people solve problems has to be
>tempered with practical implementation considerations. The API design
>that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
>course), but for us to develop a matching reference implementation we know
>now that we need to get much more information from the Sun JVM than we have
>today. Developing a full solution to match the API as it stands today is
>difficult for the Kato project as the code we would need to access is in
>OpenJDK and is under the GPL.
>
>Practically, we have few choices. We could
>
>1 - Get a JVM Vendor to produce , or commit to produce an implementation
>that fully covers the Image API side.
>2 - Remove all the Image API side from the design
>3 - Find a halfway point where some of the Image API stays and is optional.
>
>I've had many conversations with people concerning option 1 and the
>response
>is generally that its too expensive for the potential return. Both for
>implementation and ongoing maintenance.
>
>Option 2 seems very draconian - the ability to get at some of the native
>information (such as the native thread for a Java thread) just seems too
>useful to remove.
>
>I'd opt for us moving the API design towards option 3 - there are some
>basic
>changes we could do such as extracting the native access methods into a
>separate interface and allowing the implementer the choice to use it.
>
>We still need to get access to more data from the JVM (and perhaps in
>better
>ways) than we have today. We need to get this data in such a manner as not
>to require accessing GPL code and in a way that is cheap to maintain as the
>JVM evolves.
>
>My idea for resolving this conundrum is to propose that we include in our
>API design either a new JVM 'C' API or extensions to JVMTI. We would not
>implement these additions in the RI but would rely on others to provide an
>implementation. (We would design the RI and the API to make this extra
>information optional)
>
>Comments?
>
>
>--
>Steve