You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-spec@incubator.apache.org by Stuart Monteith <st...@stoo.me.uk> on 2012/01/18 10:39:50 UTC
Fwd: Re: Kato status (Was: Actively retiring projects)
Hi,
I'm cross posting this between kato-dev and kato-spec as it is
important to both the Kato incubator and JSR-326. It is a discussion on
the general incubator mailing list.
There is also a discussion, initiated by Robert, about parking the Kato
incubator "[VOTE] Park Kato". There have also been discussions on the
reporting for Kato.
Either way, please read. A decision will have to be made soon about what
to do about Kato. I'd rather we decide rather than having that decision
made for us.
Regards,
Stuart
-------- Original Message --------
Subject: Re: Kato status (Was: Actively retiring projects)
Date: Mon, 16 Jan 2012 13:13:23 +0000
From: Robert Burrell Donkin <ro...@gmail.com>
Reply-To: general@incubator.apache.org
To: general@incubator.apache.org
On Mon, Jan 16, 2012 at 12:37 PM, Jukka Zitting
<ju...@gmail.com> wrote:
> Hi,
>
> There seems to be some people assuming that the IPMC wants to
> terminate the Kato podling. Looking back I wonder if my original
> status review was the source of this:
:-)
> On Sun, Jan 8, 2012 at 1:46 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> On Wed, Nov 16, 2011 at 9:36 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>> 2008-11-06 Kato
>>
>> S: Zero activity.
>> R: Terminate.
>
> This was based on looking at commit and kato-dev@ list activity, both
> zero or very low for an extended amount of time. There was no recent
> status report.
AFAICT Soon after entry, the standards process stalled. This stopped
active development. Most of the activity after then has been the
community trying to find a way around the standards issue, with little
success. Progress depends on Oracle coming to a decision (one way or
the other) about the future of the standard. This might happen today,
tomorrow or in ten years time.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Kato status (Was: Actively retiring projects)
Posted by Steve Poole <sp...@googlemail.com>.
On Tue, Jan 31, 2012 at 4:36 PM, Stuart Monteith <st...@stoo.me.uk> wrote:
> On 27/01/12 14:22, Steve Poole wrote:
>
>> Stuart - comments inlined...
>>
>> On Fri, Jan 27, 2012 at 12:15 AM, Stuart Monteith<st...@stoo.me.uk>**
>> wrote:
>>
>>
>>> >-8 snip
>>
>>
>>> 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.
>>
> Yes - I think the answer is to produce something that would be in demand.
> Kato won't graduate without a viable community.
>
>
>
>> 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
>> attractive.
>>
>
> Yes - I have my doubts though about making "dbx for corefiles" produce
> useful information and also have it reliable and have a low overhead.
> Obviously we'll exploit any improvements to JVM diagnostics as and when
> they come along.
>
>
>>
>>> 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:
>>>
>>> -8 snip
>>>
>>>
>>> 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.
>>
> >
>
> I agree - let's ignore the JSR for now. The API is now a means to an end,
> rather than a end in itself. The goal of the Kato project then changes to
> produce post-mortem debugging tooling, and other offline JVM debugging
> tooling.
>
> I propose we should vote on changing the projects goals. We do want to be
> clear on what we are trying to achieve - otherwise people won't know if
> they should be interested.
>
> Fine by me. Who gets to vote?
> Can we produce something that is compelling?
>>>
>>> -8 Snip
>>>
>>> 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
>> top.
>> 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 :-)
>>
>>
> The modules we have for the CLI (i.e. Tomcat diagnosis) could be one
> approach. I still like the idea of FFDC tools that perform FFDC without
> having to explicitly store information that might be incomplete. I will
> have to rethink in more detail about what we have and how I'd like to
> contribute.
>
>
> Regards,
> Stuart
>
--
Steve
Re: Kato status (Was: Actively retiring projects)
Posted by Stuart Monteith <st...@stoo.me.uk>.
On 27/01/12 14:22, Steve Poole wrote:
> Stuart - comments inlined...
>
> On Fri, Jan 27, 2012 at 12:15 AM, Stuart Monteith<st...@stoo.me.uk>wrote:
>
>>
> >-8 snip
>>
>> 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.
Yes - I think the answer is to produce something that would be in
demand. Kato won't graduate without a viable community.
>
> 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
> attractive.
Yes - I have my doubts though about making "dbx for corefiles" produce
useful information and also have it reliable and have a low overhead.
Obviously we'll exploit any improvements to JVM diagnostics as and when
they come along.
>
>>
>> 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:
>>
>>-8 snip
>>
>> 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.
>
I agree - let's ignore the JSR for now. The API is now a means to an
end, rather than a end in itself. The goal of the Kato project then
changes to produce post-mortem debugging tooling, and other offline JVM
debugging tooling.
I propose we should vote on changing the projects goals. We do want to
be clear on what we are trying to achieve - otherwise people won't know
if they should be interested.
>> Can we produce something that is compelling?
>>
>>-8 Snip
>> 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
> top.
> 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 :-)
>
The modules we have for the CLI (i.e. Tomcat diagnosis) could be one
approach. I still like the idea of FFDC tools that perform FFDC without
having to explicitly store information that might be incomplete. I will
have to rethink in more detail about what we have and how I'd like to
contribute.
Regards,
Stuart
Re: Kato status (Was: Actively retiring projects)
Posted by Steve Poole <sp...@googlemail.com>.
Stuart - comments inlined...
On Fri, Jan 27, 2012 at 12:15 AM, Stuart Monteith <st...@stoo.me.uk>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
attractive.
>
> 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
top.
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 :-)
Goodnight,
> 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<st...@stoo.me.uk>**
>> wrote:
>> -8 Snip!
>>
>>>
>>>
>>
>>
>
--
Steve
Re: Kato status (Was: Actively retiring projects)
Posted by Steve Poole <sp...@googlemail.com>.
Stuart - comments inlined...
On Fri, Jan 27, 2012 at 12:15 AM, Stuart Monteith <st...@stoo.me.uk>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
attractive.
>
> 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
top.
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 :-)
Goodnight,
> 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<st...@stoo.me.uk>**
>> wrote:
>> -8 Snip!
>>
>>>
>>>
>>
>>
>
--
Steve
Re: Kato status (Was: Actively retiring projects)
Posted by Stuart Monteith <st...@stoo.me.uk>.
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.
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 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
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.
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?
Goodnight,
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<st...@stoo.me.uk>wrote:
>-8 Snip!
>>
>
>
Oracle's position on the JSR-326
Posted by "serguei.spitsyn@oracle.com" <se...@oracle.com>.
Hi Kato experts,
Steve and Stuart asked me to share the Oracle's position on the JSR-326
with the Kato members.
(Sorry, I originally sent the message below to the wrong Kato mailing
list in Jan 5th.)
I'll try to summarize the key points expressed in the Oracle internal
discussion.
- While the API looks like a good idea, the priority is not high for Oracle.
Oracle has no community input indicating that this is widely
requested or should be prioritized.
The primary use case is probably in support scenarios in Oracle, IBM,
etc.
- The target audience is very limited.
The number of developers or end users that could make use of the API
is small.
It is unlikely this API is useful for general Java developers.
- Our resources are limited, and there are bigger items on our plate for
JDK 8.
If it can be made into something we think would be valuable for Java
developers,
at a level that justifies putting resources on it, then we should
consider it.
But it does not sound like it as presently proposed.
It would make sense to collect more feedback from the community and
customers
to find a good approach. It does not look that it can be done in the JDK
8 time frame.
Please, ask questions and share any points that could convince Oracle
management to change this position.
Thanks,
Serguei
Re: Kato status (Was: Actively retiring projects)
Posted by "serguei.spitsyn@oracle.com" <se...@oracle.com>.
Hi Steve,
It looks like I've mistakenly sent my email to the wrong mailing list:
kato-spec-subscribe@incubator.apache.org
Please, see my original email attached below.
Sorry for that. :(
I'll re-post it to the correct mailing list.
Thanks,
Serguei
Hi Kato experts,
Steve and Stuart asked me to share the Oracle's position on the JSR-326
with the Kato members.
I'll try to summarize the key points expressed in the Oracle internal
discussion.
- While the API looks like a good idea, the priority is not high for Oracle.
Oracle has no community input indicating that this is widely
requested or should be prioritized.
The primary use case is probably in support scenarios in Oracle, IBM,
etc.
- The target audience is very limited.
The number of developers or end users that could make use of the API
is small.
It is unlikely this API is useful for general Java developers.
- Our resources are limited, and there are bigger items on our plate for
JDK 8.
If it can be made into something we think would be valuable for Java
developers,
at a level that justifies putting resources on it, then we should
consider it.
But it does not sound like it as presently proposed.
It would make sense to collect more feedback from the community and
customers
to find a good approach. It does not look that it can be done in the JDK
8 time frame.
Please, ask questions and share any points that could convince Oracle
management to change this position.
Thanks,
Serguei
On 1/26/12 8:53 AM, 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<st...@stoo.me.uk>wrote:
>
>> Hi,
>> I'm cross posting this between kato-dev and kato-spec as it is
>> important to both the Kato incubator and JSR-326. It is a discussion on the
>> general incubator mailing list.
>>
>> There is also a discussion, initiated by Robert, about parking the Kato
>> incubator "[VOTE] Park Kato". There have also been discussions on the
>> reporting for Kato.
>>
>> Either way, please read. A decision will have to be made soon about what
>> to do about Kato. I'd rather we decide rather than having that decision
>> made for us.
>>
>> Regards,
>> Stuart
>>
>> -------- Original Message --------
>> Subject: Re: Kato status (Was: Actively retiring projects)
>> Date: Mon, 16 Jan 2012 13:13:23 +0000
>> From: Robert Burrell Donkin<robertburrelldonkin@gmail.com**>
>> Reply-To: general@incubator.apache.org
>> To: general@incubator.apache.org
>>
>> On Mon, Jan 16, 2012 at 12:37 PM, Jukka Zitting<ju...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> There seems to be some people assuming that the IPMC wants to
>>> terminate the Kato podling. Looking back I wonder if my original
>>> status review was the source of this:
>>>
>> :-)
>>
>> On Sun, Jan 8, 2012 at 1:46 PM, Jukka Zitting<ju...@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Nov 16, 2011 at 9:36 PM, Sam Ruby<ru...@intertwingly.net>
>>>> wrote:
>>>>
>>>>> 2008-11-06 Kato
>>>>>
>>>> S: Zero activity.
>>>> R: Terminate.
>>>>
>>> This was based on looking at commit and kato-dev@ list activity, both
>>> zero or very low for an extended amount of time. There was no recent
>>> status report.
>>>
>> AFAICT Soon after entry, the standards process stalled. This stopped
>> active development. Most of the activity after then has been the
>> community trying to find a way around the standards issue, with little
>> success. Progress depends on Oracle coming to a decision (one way or
>> the other) about the future of the standard. This might happen today,
>> tomorrow or in ten years time.
>>
>> Robert
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<ge...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.**org<ge...@incubator.apache.org>
>>
>>
>
Oracle's position on the JSR-326
Posted by "serguei.spitsyn@oracle.com" <se...@oracle.com>.
Hi Kato experts,
Steve and Stuart asked me to share the Oracle's position on the JSR-326
with the Kato members.
(Sorry, I originally sent the message below to the wrong Kato mailing
list in Jan 5th.)
I'll try to summarize the key points expressed in the Oracle internal
discussion.
- While the API looks like a good idea, the priority is not high for Oracle.
Oracle has no community input indicating that this is widely
requested or should be prioritized.
The primary use case is probably in support scenarios in Oracle, IBM,
etc.
- The target audience is very limited.
The number of developers or end users that could make use of the API
is small.
It is unlikely this API is useful for general Java developers.
- Our resources are limited, and there are bigger items on our plate for
JDK 8.
If it can be made into something we think would be valuable for Java
developers,
at a level that justifies putting resources on it, then we should
consider it.
But it does not sound like it as presently proposed.
It would make sense to collect more feedback from the community and
customers
to find a good approach. It does not look that it can be done in the JDK
8 time frame.
Please, ask questions and share any points that could convince Oracle
management to change this position.
Thanks,
Serguei
Re: Re: Kato status (Was: Actively retiring projects)
Posted by Steve Poole <sp...@googlemail.com>.
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 <st...@stoo.me.uk>wrote:
> Hi,
> I'm cross posting this between kato-dev and kato-spec as it is
> important to both the Kato incubator and JSR-326. It is a discussion on the
> general incubator mailing list.
>
> There is also a discussion, initiated by Robert, about parking the Kato
> incubator "[VOTE] Park Kato". There have also been discussions on the
> reporting for Kato.
>
> Either way, please read. A decision will have to be made soon about what
> to do about Kato. I'd rather we decide rather than having that decision
> made for us.
>
> Regards,
> Stuart
>
> -------- Original Message --------
> Subject: Re: Kato status (Was: Actively retiring projects)
> Date: Mon, 16 Jan 2012 13:13:23 +0000
> From: Robert Burrell Donkin <robertburrelldonkin@gmail.com**>
> Reply-To: general@incubator.apache.org
> To: general@incubator.apache.org
>
> On Mon, Jan 16, 2012 at 12:37 PM, Jukka Zitting <ju...@gmail.com>
> wrote:
>
>> Hi,
>>
>> There seems to be some people assuming that the IPMC wants to
>> terminate the Kato podling. Looking back I wonder if my original
>> status review was the source of this:
>>
>
> :-)
>
> On Sun, Jan 8, 2012 at 1:46 PM, Jukka Zitting <ju...@gmail.com>
>> wrote:
>>
>>> On Wed, Nov 16, 2011 at 9:36 PM, Sam Ruby <ru...@intertwingly.net>
>>> wrote:
>>>
>>>> 2008-11-06 Kato
>>>>
>>>
>>> S: Zero activity.
>>> R: Terminate.
>>>
>>
>> This was based on looking at commit and kato-dev@ list activity, both
>> zero or very low for an extended amount of time. There was no recent
>> status report.
>>
>
> AFAICT Soon after entry, the standards process stalled. This stopped
> active development. Most of the activity after then has been the
> community trying to find a way around the standards issue, with little
> success. Progress depends on Oracle coming to a decision (one way or
> the other) about the future of the standard. This might happen today,
> tomorrow or in ten years time.
>
> Robert
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<ge...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.**org<ge...@incubator.apache.org>
>
>
--
Steve
Re: Re: Kato status (Was: Actively retiring projects)
Posted by Steve Poole <sp...@googlemail.com>.
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 <st...@stoo.me.uk>wrote:
> Hi,
> I'm cross posting this between kato-dev and kato-spec as it is
> important to both the Kato incubator and JSR-326. It is a discussion on the
> general incubator mailing list.
>
> There is also a discussion, initiated by Robert, about parking the Kato
> incubator "[VOTE] Park Kato". There have also been discussions on the
> reporting for Kato.
>
> Either way, please read. A decision will have to be made soon about what
> to do about Kato. I'd rather we decide rather than having that decision
> made for us.
>
> Regards,
> Stuart
>
> -------- Original Message --------
> Subject: Re: Kato status (Was: Actively retiring projects)
> Date: Mon, 16 Jan 2012 13:13:23 +0000
> From: Robert Burrell Donkin <robertburrelldonkin@gmail.com**>
> Reply-To: general@incubator.apache.org
> To: general@incubator.apache.org
>
> On Mon, Jan 16, 2012 at 12:37 PM, Jukka Zitting <ju...@gmail.com>
> wrote:
>
>> Hi,
>>
>> There seems to be some people assuming that the IPMC wants to
>> terminate the Kato podling. Looking back I wonder if my original
>> status review was the source of this:
>>
>
> :-)
>
> On Sun, Jan 8, 2012 at 1:46 PM, Jukka Zitting <ju...@gmail.com>
>> wrote:
>>
>>> On Wed, Nov 16, 2011 at 9:36 PM, Sam Ruby <ru...@intertwingly.net>
>>> wrote:
>>>
>>>> 2008-11-06 Kato
>>>>
>>>
>>> S: Zero activity.
>>> R: Terminate.
>>>
>>
>> This was based on looking at commit and kato-dev@ list activity, both
>> zero or very low for an extended amount of time. There was no recent
>> status report.
>>
>
> AFAICT Soon after entry, the standards process stalled. This stopped
> active development. Most of the activity after then has been the
> community trying to find a way around the standards issue, with little
> success. Progress depends on Oracle coming to a decision (one way or
> the other) about the future of the standard. This might happen today,
> tomorrow or in ten years time.
>
> Robert
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<ge...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.**org<ge...@incubator.apache.org>
>
>
--
Steve