incubator-kato-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: Kato status (Was: Actively retiring projects)
Date Fri, 27 Jan 2012 00:15:55 GMT
	We finally have a definitive position from Oracle - thanks for posting 

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.

2. The target audience is very limited.

3. Oracle's resources are limited, and the JSR is targeted at a limited 

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 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.

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 

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.

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?


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!

View raw message