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.
Summary: | I18N - mac - won't generate javadoc if project name or path has multibyte | ||
---|---|---|---|
Product: | java | Reporter: | Ken Frank <kfrank> |
Component: | Project | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | jf4jbug, jpokorsky, kaa |
Priority: | P2 | Keywords: | I18N, RELNOTE |
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | Mac OS X | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | image |
Description
Ken Frank
2008-03-18 05:17:45 UTC
Created attachment 58536 [details]
image
Reassigning to java/j2seproject that implements the generate javadoc action. Not fixable in NB, see also #118203 which has the same root case. The problem is that javadoc task while creating the temporary parameter file writes into it in default OS encoding which is MacRoman. I am not expert regarding MacRoman but it seems that it's not able to encode japanese mbytes, in my case everything was converted into 0x3F. But it's not an issue of Apache javadoc task - the assumption that the system encoding is able to hold the file names seems reasonable, it seems as an Apple problem where the BSD and Mach parts (system & kernel calls) accept parameters in UTF-8 but OS and HFS promotes themselves as MacRoman. The only workaround that I found is to override -javadoc-build target in the build.xml and disable useexternalfile. Interesting link may be also: http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Articles/FileEncodings.html#//apple_ref/doc/uid/20002137- DontLinkElementID_2 According to it seems that the behavior differs depending on FS type. |