Thread safety documentation
in [Java Programming]
|
Prev: FireFoc support forums (Re: FF3.6 Stack output from Too MuchRecursion)
Next: Call for Papers Reminder (extended): The World Congress on Engineering WCE 2010
From: Patricia Shanahan on 8 Mar 2010 18:57 The "Calendar.getInstance() thread safe?" is yet another instance of a recurring problem with Java APIs, the lack of consistent documentation and default rules for thread safety. Often, these questions can only be resolved by examination of the source code, which is unsatisfactory because it is vulnerable to future changes that would preserve everything that is documented. I now have some free time, and would like to try to contribute to a resolution of the problem. Is there an existing effort I should join, or do I need to start a new one? Patricia
From: Arne Vajhøj on 8 Mar 2010 19:06 On 08-03-2010 18:57, Patricia Shanahan wrote: > The "Calendar.getInstance() thread safe?" is yet another instance of a > recurring problem with Java APIs, the lack of consistent documentation > and default rules for thread safety. Often, these questions can only be > resolved by examination of the source code, which is unsatisfactory > because it is vulnerable to future changes that would preserve > everything that is documented. > > I now have some free time, and would like to try to contribute to a > resolution of the problem. Is there an existing effort I should join, or > do I need to start a new one? It would be a lot more useful if the work got merged into the official docs for the very same reasons you mention for looking at source code. Arne
From: Patricia Shanahan on 8 Mar 2010 19:11 Arne Vajh�j wrote: > On 08-03-2010 18:57, Patricia Shanahan wrote: >> The "Calendar.getInstance() thread safe?" is yet another instance of a >> recurring problem with Java APIs, the lack of consistent documentation >> and default rules for thread safety. Often, these questions can only be >> resolved by examination of the source code, which is unsatisfactory >> because it is vulnerable to future changes that would preserve >> everything that is documented. >> >> I now have some free time, and would like to try to contribute to a >> resolution of the problem. Is there an existing effort I should join, or >> do I need to start a new one? > > It would be a lot more useful if the work got merged into > the official docs for the very same reasons you mention for > looking at source code. Yes, I believe any good resolution of this problem will end with the necessary information in the official documentation. Ironically, Sun did this for Solaris documentation many years ago. Every system call or function has an "MT-Level", which has to be one of a defined set of levels, specified in its man page. Although I am not sure the Solaris MT-Level values all make sense for Java, they provide a possible starting point with real world experience. Patricia
From: Arved Sandstrom on 8 Mar 2010 19:12 Patricia Shanahan wrote: > The "Calendar.getInstance() thread safe?" is yet another instance of a > recurring problem with Java APIs, the lack of consistent documentation > and default rules for thread safety. Often, these questions can only be > resolved by examination of the source code, which is unsatisfactory > because it is vulnerable to future changes that would preserve > everything that is documented. > > I now have some free time, and would like to try to contribute to a > resolution of the problem. Is there an existing effort I should join, or > do I need to start a new one? > > Patricia If it's simply a matter of documentation, it seems to me that JCIP made a good start with Appendix A, Annotations for Concurrency. AHS
From: markspace on 9 Mar 2010 10:52
Arved Sandstrom wrote: > Patricia Shanahan wrote: >> The "Calendar.getInstance() thread safe?" is yet another instance of a >> recurring problem with Java APIs, the lack of consistent documentation >> and default rules for thread safety. Often, these questions can only be >> resolved by examination of the source code, which is unsatisfactory >> because it is vulnerable to future changes that would preserve >> everything that is documented. >> >> I now have some free time, and would like to try to contribute to a >> resolution of the problem. Is there an existing effort I should join, or >> do I need to start a new one? >> >> Patricia > > If it's simply a matter of documentation, it seems to me that JCIP made > a good start with Appendix A, Annotations for Concurrency. I agree with you. However in one of the "public contribution" phases of Java 7, I suggested this and it was rejected out of hand. I don't believe Sun understands or agrees with the need for this sort of documentation. I should add that I suggested these annotations be added to the core language, like @Override is, and they rejected it because they felt these annotations should be part of the Java doc controls and an API issue rather than a language feature. I happen to disagree with them. I think that the compiler could check thread safety correctness, according to declared annotations, and it would be a big benefit for Java programmers. I'm not sure what the effort involved would be, but I'm sure it's less than debugging threading issues in all Java programs in existence. (Note I didn't suggest all this, just that they get the JCiP annotations in the language so folks could start using them.) Oh and to answer Patricia's original request, no I don't know of any thread safety efforts related to Sun's API. If you find some, Patricia, please let us know. I'd be interested in contributing to the effort myself. |