incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <>
Subject Re: Kato status (Was: Actively retiring projects)
Date Fri, 27 Jan 2012 14:22:27 GMT
Stuart - comments inlined...

On Fri, Jan 27, 2012 at 12:15 AM, Stuart Monteith <>wrote:

> Hello,
>        We finally have a definitive position from Oracle - thanks for
> posting Serguei.
> Serguei states Oracle's position in a number of points, which I'll
> brutally summarize here:
> 1. While the API is a good idea, there is no demand from the community.

I agree that is true now -  it wasn't when we started.

2. The target audience is very limited.
> 3. Oracle's resources are limited, and the JSR is targeted at a limited
> audience.
> 4. Would need more feedback from the community - but wouldn't be done in
> the JDK 8 time frame.
> We've been through the process of getting community feedback. The response
> was generally positive. Steve can fill us in further.

The promise of the tools we put together did attract a lot of attention -
the long delay in delivering them has obviously turned people off.
The idea of the Java equivilent of  "dbx for corefiles" is always

> The target audience for the API was limited - tool vendors and JDK
> support. The target audience for the tools that were to be based on the
> Kato API were Java developers, support, and operations.
> My view is that while the API is an interesting concept, it is too low a
> level for there ever to be community interest in it's development - there
> are so few vendors. When we started this there was at least Sun, Oracle
> (who had just bought BEA), Intel and IBM. Now we are reduced to Oracle and
> IBM, which is a very small community indeed, and as they are both
> cooperating somewhat through OpenJDK that is even smaller.
> Yes agreed.

> I see us continuing in the following form:
> 1. JSR-326 continues on its standardization of the API. The API as it is
> no longer considered part of the Kato project, and isn't actively developed
> here.

> 2. Kato continues with the development of API implementations for the
> HotSpot JVM of whatever formats it makes available, or we can make
> available.
> 3. IBM makes available its implementations of JSR 326.
> 4. We write useful tooling in Kato that make use of JSR-326.
> 5. Once we have something compelling for the community to use and build
> on, demand becomes so great that efforts in OpenJDK snowball and a
> post-mortem diagnostics community becomes self sustaining.
> I agree with all these points but I would point out that we said at the
beginning of Kato that the JSR 326 spec would just "fall out" of the Kato
implementation - ie a code lead spec.   That's still true so I think we
should reserve judgement on the disconnection of JSR 326 from Kato.   I'd
rather ignore it for now. We should just focus on producing the tools and
supporting API we want and worry about any form of standardisation later.

Can we produce something that is compelling?
> Allowing people to attach their existing debuggers to JVM dumps would be a
> good improvement on the existing situation. In the world of 10's of GBs of
> heap it is less compelling, but for desktop and smaller applications, it is
> more practicable. Java is still behind the likes of gdb and dbx in this
> respect. I imagine the ordinary Java developer could benefit from this.
> But is there anything else?

Creating a connector between jdi and a dump is good and useful since it
makes use of a familiar interface.   I would like to go further and produce
more comprehensive diagnostic tools that would not fit into the jdi model.

I mentioned serialisation before as one example.  Take a serialisation
stream and present it in a graphical view.  For deserialisation failures
take a set of classes and a serialisation stream and show where and how the
stream doesnt match the classes provided.    That one really bugs me. At my
Serialisation talk at JavaOne last year I got a ton of people asking how to
debug these sorts of problems.

Other ideas :

change or compliment the API with something more SAX style related (rather
than the DOM style we have today)   and add a good query mechanism on
Implement the snapshot dump API so that we can get smaller dumps.
Create Eclipse plugins for these new things so that developers have a
better experience than a command line tool.

I'm sure I will think of others :-)

>    Stuart
> On 26/01/12 16:53, Steve Poole wrote:
>> Hi all.
>> Apache Kato was initially created  to develop the specification and
>> reference implementation for JSR 326.   That is by definition a
>> cross-industry activity.   To complete the JSR and create an industry
>> standard API we need  a community which has  participants on both sides of
>> the API:  those who would use the API to access data  and those  who would
>> provide the data to be read.  Without a  broad  consumer/provider
>> community
>> we are not going to be able to complete the JSR any time soon.
>> The rebooting of the OpenJDK community and new  input from Oracle on their
>> situation  leads me to suggest a new direction for Kato at this time.
>>  I hope that  Oracle will post their own statement  but I think it's fair
>> for me to say that, at this point,   they have other business concerns
>> that
>> are more pressing than helping us out right now.   That may change later.
>> The good news is that with the OpenJDK reboot  we  have a real opportunity
>> to address some of our technical challenges  directly without requiring
>> Oracles assistance.   I'm already an active participant in OpenJDK and I
>> do
>> intend to scratch a few itches over time that way.
>> Given all that I'd like to propose the following simple plan to revitalise
>> Apache Kato
>> 1 - We ignore or put on hold  the JSR work. With limited involvement from
>> Oracle at the moment  we have to assume that its not going to complete
>> anytime soon and maybe never.
>> 2 - We refocus Kato towards  post-mortem diagnostics tools.  We already
>> have a good set of tools and I'd like to improve them and add more.  For
>> instance  I have some ideas for a Java serialization diagnostics tool that
>> would fit well here.
>> 3 - Where we find a need for new data from the JVM we (as individuals)
>> work
>> with the  OpenJDK community to make that happen.
>> On Wed, Jan 18, 2012 at 10:39 AM, Stuart Monteith<>**
>> wrote:
>> -8 Snip!


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