incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: Java Language abstraction layer
Date Tue, 20 Oct 2009 17:32:35 GMT
+1

I'd like to broaden the utility of generating concrete Collection 
instances by having that potentially apply
to any class.

For example:

package javax.tools.diagnostics.language.java;

public interface JavaObjectSolidifier {
    public Object solidifyObject(JavaObject);
}

public interface JavaView {
       public Object solidifyObject(JavaObject obj, Class concreteType) 
throws IllegalArgumentException;

       public void registerSolidifier(JavaObjectSolidifier solidifier, 
Class type);
}

So you could call:
    List list = view.solidifyObject(obj, List.class);

    System.out.println("List size="+list.size());

and this would allow callers to also register their own concrete types 
too. For applications, this might not be too

One of the points to consider is different SDK implementations. My 
expectation would be that each implementation
of the API would supply it's own implementations of "JavaObjectSolidifier".

Also, "Solidifier" is not necessarily the best of names. "Instantiator" 
might be better.

I'll follow up with further thoughts.


Steve Poole wrote:
> 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
> harder)
>
> 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 javax.tools.diagnostics.runtime.java   from Java* to JVM*
> (as they are more JVM focused )  and introducing a new package called
> javax.tools.diagnostics.language.java   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.
>
>
>
>   

-- 
Stuart Monteith
http://blog.stoo.me.uk/


Mime
View raw message