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.
This is NOT related to other javadoc issues filed on various project types in which firefox, mostly on solaris but sometimes on windows and I think on mac, does not show javadoc if multibyte is used in project name and path (sometimes using utf-8 project encoding, sometimes only when using just other project encodings. Those issues have been partially fixed but from looking at the issues it seems its a firefox problem also ? This one: 1. am in mac in ja locale, using pseudo localized netbeans but that is not required. 2. create a j2se project for example, and have directory leading to project dir have multibyte in its name and/or have the project name itself have multibyte. 3. generate javadoc 4. get errors as in attached gif and nothing is placed in the dist/javadoc dir. PS some of the other previous issues about firefox and finding path to javadoc are 106944 108321 108322 108323
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.