JDK-4140384 : design bug: ambiguous "first sentence" rule
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-05-20
  • Updated: 2014-05-05
  • Resolved: 1999-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.2.0 1.2fcsFixed
Related Reports
Duplicate :  
Relates :  
Description

Name: rm29839			Date: 05/20/98


The rule for which text from a method's document
comment that JavaDoc includes in the method index
is ambiguous, or at least is not fully compatible
with normal English punctuation.

For example, see the Method Summary section for
UndoableEdit:  

 String 
       getRedoPresentationName() 
           Provide a localized, human readable 
           description of the redoable form of 
           this edit, e.g.
 
 String 
       getUndoPresentationName() 
           Provide a localized, human readable 
           description of the undoable form of 
           this edit, e.g. 

JavaDoc shouldn't be trying to parse English
sentences, given that that's nontrivial and
given that it doesn't get it right.

JavaDoc should use something less ambiguous to
define the separation between the introductory
text (included in the index) from the detailed
description (included only in the full method
description).

You should use something like a blank line, an
HTML tag (e.g., <P>), or something else definite
like those, to separate the index comment from 
the full description.

Also, JavaDoc overdefines the policy that the
index comment is one sentence.  That is, if one
really needs to be two sentences, the programmer/
documenter should be stopped by the tool from
doing that.

Please think about cleaning up this behavior
a bit.
(Review ID: 28765)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2fcs FIXED IN: 1.2fcs INTEGRATED IN: 1.2fcs
14-06-2004

WORK AROUND Name: rm29839 Date: 05/20/98 Working around this JavaDoc behavior can require using something other than the ideal or preferred wording in documentation ======================================================================
11-06-2004

PUBLIC COMMENTS Fixed. If the locale language is "en"(english), then the first sentence is identified as "." followed by space, \n, \r, \f, \t. atul.dambalkar@eng 1998-08-07
07-08-1998

SUGGESTED FIX Don't use BreakIterator for English language locale, but use previous criteria of dot ('.') followed by space (' '). atul.dambalkar@eng 1998-07-29
29-07-1998

EVALUATION We cannot change the mechanism by which the first sentence (to a period) is used as the summary because it is defined in the JLS, section 18.3 "This sentence ends at the first period that is followed by a blank, tab, or line terminator." BTW: this means the current implementation is not correct because it does not check for the white space. I think the correct course of action is to fix the whitespace problem, then add a "@summary" tag that will override the first sentence rule. This gives backward compatibility and flexibility. robert.field@Eng 1998-05-21 Javadoc is now fully Localized and it now uses java.text.BreakIterator for creating the sentence boundaries, in other words, the first sentence is decided by java.text.BreakIterator, depending upon the Locale. So "@summary" tag will be a better solution. atul.dambalkar@eng 1998-05-21 From dkramer@taller Thu May 21 21:33:04 1998 | From shannon@datsun Thu May 21 20:54:42 1998 | | String | getRedoPresentationName() | Provide a localized, human readable | description of the redoable form of | this edit, e.g. | | Of course, "e.g." should be followed by a comma, not whitespace. | | And isn't it part of our style that we say "for example" instead | of "e.g."? Yep on both counts. The workaround is to put any non-printing HTML character after the period, such as a hard space: This method was written by Dr.&nbsp;Gosling. or a no-op comment: This method was written by Dr.<!-- -->Gosling These are documented at: http://java.sun.com/products/jdk/javadoc/writingdoccomments.html#descriptions However, the reverse happens where people accidentally run past the first sentence: This is the first sentence.<p> This is the second sentence. Because there is no space immediately after the period, javadoc picks up the above two combined sentences as the first sentence. -Doug 6/98 Here's another example: * Check whether the flag specified in the given <code>Flags.Flag</code> * object is set in this Message. <p> Good grief. The workarounds have changed since we recently internationalized the sentence separator. The old workaround for this case no longer works. I just tried the old workaround, putting an HTML comment after the period, but it no longer works: <code>Flags.<!-- -->Flag</code> Here's a new, extremely ugly workaround that will work on 4.0 browsers. Use this entity for the period: &#046; Works in Netscape 3.0/4.0 and IE 3.0/4.0 <code>Flags&#046;Flag</code> This works. (I'll document it) Atul, would you please add either add the example below to the BreakIterator bug bugtraq Perhaps someday this entity will be adopted: &period; Does not work in Netscape 3.0 or 4.0 or IE 3.0 or 4.0. Works in Emacs browser :) I changed this to priority 4 so I will remember to document it. Then I should re-assign it to Atul. doug.kramer@Eng 1998-07-16 Since Javadoc is now Internationalized, it depends entirely on the java.text.BreakIterator to break the first sentence. The Related bug on BreakIterator is 4113835. atul.dambalkar@eng 1998-07-17 Bill Shannon also submitted a related BreakIterator bug # 4158381. doug.kramer@Eng 1998-07-24
17-07-1998