This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 131885 - Generated javadoc comment contains character reference
Summary: Generated javadoc comment contains character reference
Status: NEW
Alias: None
Product: uml
Classification: Unclassified
Component: Code Generation (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@uml
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-03 04:45 UTC by frogcoder
Modified: 2009-05-25 21:06 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description frogcoder 2008-04-03 04:45:32 UTC
The document content is copied to the javadoc comment in generated code.  We have our documenatation in Chinese 
characters.  Since javadoc comment is in HTML format, everything is escaped to character reference.  The result 
document looks fine in generated javadoc html document and in navigation panel, but in java code, they are just bunch 
of character references, not readable by human.  Only special characters should be escaped but not every character in 
the document.
Comment 1 frogcoder 2008-04-03 04:46:55 UTC
a sample output

/**
 *  <p style="margin-top: 0">
 *    &#25104;&#20154;&#24433;&#29255;&#28436;&#21729;
 *      </p>
 */
Comment 2 Yang Su 2008-09-26 00:11:52 UTC
Documentation window uses HTMLEditorKit, so the JTextPane.getText() by default yields escaped html character, that
translates mbyte characters into &#nnn; format. It works fine for saving and retrieving documentation text in project
xml file, rending in documentation editor and html report. However, the downside is we need to process the character
sequence before writing to source file in order to render the native characters correctly in Java source editor.
Similarly, it is necessary to escape them during reverse engineering to maintain the current encoding scheme for
documentation persistence. 

So the suggested fix is to add logic to encode/decode html strings for code generation and reverse engineering. Some
potential issues in merging source code with mbyte documentation need to be investigated along with this approach,
assign to Viktor.