incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <>
Subject Do we need to change the scope of the API design?
Date Wed, 25 Nov 2009 13:44:24 GMT
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)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message