incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <>
Subject Java Language abstraction layer
Date Tue, 20 Oct 2009 15:17:46 GMT
I've mentioned a couple of times that I want to add an extra abstraction to
the API.   Its been on the list since (almost) day 1.

If you consider the Image and JavaRuntime  APIs that we have now you can see
that are designed to present exactly what's there - and as a result  the
main users of these APIs are mostly  people interested in solving JVM
problems.     Its quite feasible to solve Java application problems but only
by putting  a large burden on the user.        An example of this burden can
be imagined if you consider what is required to be done if you want to find
JavaObjects that implement a named interface or one of its children.    As a
user of the API you have to create a class hierarchy for the interface and
then visit every class to see if it implements one of the named
interfaces.   (If you take class loading into consideration it gets even

We need to provide an API where you can (for example) simply ask for
JavaObjects that implement an interface!

So the intention of this additional API will be to hide some of the Java
runtime complexity and lift much of the burden from the user.    Some
examples would be   flattening the multiple heap architecture and squashing
the corruptdata and dataunavailable exceptions.    At least for the RI I
expect to be able to build this new API on top of the existing one.

There is also the possibility of architecting in a solution to the
Collection classes virtualisation problem discussed before.

Here's what I propose to do next

Firstly, deal with a potential name clash issue by  renaming as appropriate
the classes in the   from Java* to JVM*
(as they are more JVM focused )  and introducing a new package called   which will contain classes that map
to  those entities that a Java application programmer would expect to see -
so JavaClass , JavaClassLoader etc

Secondly, apply some form of the QueryResult  idea to the API so that lists
are gone for good.

Then move on to  build a full  example in the RI.


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