From kato-commits-return-573-apmail-incubator-kato-commits-archive=incubator.apache.org@incubator.apache.org Mon Aug 10 13:21:48 2009 Return-Path: Delivered-To: apmail-incubator-kato-commits-archive@minotaur.apache.org Received: (qmail 4134 invoked from network); 10 Aug 2009 13:21:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Aug 2009 13:21:48 -0000 Received: (qmail 58148 invoked by uid 500); 10 Aug 2009 13:21:55 -0000 Delivered-To: apmail-incubator-kato-commits-archive@incubator.apache.org Received: (qmail 58133 invoked by uid 500); 10 Aug 2009 13:21:55 -0000 Mailing-List: contact kato-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: kato-dev@incubator.apache.org Delivered-To: mailing list kato-commits@incubator.apache.org Received: (qmail 58123 invoked by uid 99); 10 Aug 2009 13:21:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Aug 2009 13:21:55 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Aug 2009 13:21:53 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 4BF302388871; Mon, 10 Aug 2009 13:21:33 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r802784 - /incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/todo.xml Date: Mon, 10 Aug 2009 13:21:33 -0000 To: kato-commits@incubator.apache.org From: monteith@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20090810132133.4BF302388871@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: monteith Date: Mon Aug 10 13:21:32 2009 New Revision: 802784 URL: http://svn.apache.org/viewvc?rev=802784&view=rev Log: Add more detail to todo.xml explaining what is missing. Modified: incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/todo.xml Modified: incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/todo.xml URL: http://svn.apache.org/viewvc/incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/todo.xml?rev=802784&r1=802783&r2=802784&view=diff ============================================================================== --- incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/todo.xml (original) +++ incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/todo.xml Mon Aug 10 13:21:32 2009 @@ -29,36 +29,65 @@ Native and Java Frame interleaving + + The API presents native stack frames and Java stack frames in different places in the API - in ImageThread + and JavaThread. This makes it difficult to understand the order in which Java methods and native functions + have been called. Exposing the interleaving of native and Java frames would help, for example, debugging + complex JNI functions. + - Optimization of data access (query support) + Optimisation of data access (query support) + + The current programmatic means of accessing data is not open to optimisation. Having a query language + would enable the creation of useful indexes to speed up queries. + - No support for identifing or handing generics in the Java Runtime + No support for identifying or handing generics in the Java Runtime + + Currently it is impossible to determine any of the generic type information that is available in + JVMs implementing Java 5.0 or above. + - No support for thread groups in the Java Runtime + No support for thread groups in the Java Runtime + + The API has no consistent means of reporting the ThreadGroups the JavaThreads belong to. + - Lack of consitancy in accessing JavaObjects + Lack of consistency in accessing JavaObjects - Accessing data as their own type is difficult or impossible. + In order to access the contents of objects in most cases it is often necessary to implement, as accesses + via the API, at least a subset of the functionality of the methods in the class of the object being accessed. + For example, to access all of the objects in a java.util.HashMap, knowledge of how HashMap is + implemented is necessary. As HashMap can be implemented differently on different implementations of the + Java SDK, it is difficult to write programs using the API that are truly Java SDK agnostic. Need defined behaviour on what toString offers on each part of the API + + The toString() method's behaviour is not specified in sufficient details across the whole API. + For example, JavaStackFrame.toString() should return a string describing the stack location + like in a Java stacktrace, so this should be specified so it can be implemented consistently. + - Can't see the finaliser info - - - - No definitions about snapshotting + No definitions about snapshoting + + It is desirable that there be a consistent means for generating dumps for later analysis + by the API. An API to be used during runtime would enable applications to generate dumps when + it suits them. This would not be to the exclusion of other means of generating dumps + peculiar to particular JVM implementations. + - \ No newline at end of file + + \ No newline at end of file