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 130357 - I18N - mac - won't generate javadoc if project name or path has multibyte
Summary: I18N - mac - won't generate javadoc if project name or path has multibyte
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: Sun Mac OS X
: P2 blocker (vote)
Assignee: Tomas Zezula
Keywords: I18N, RELNOTE
Depends on:
Reported: 2008-03-18 05:17 UTC by Ken Frank
Modified: 2008-04-14 13:52 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

image (122.36 KB, image/gif)
2008-03-18 05:18 UTC, Ken Frank

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2008-03-18 05:17:45 UTC
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

Comment 1 Ken Frank 2008-03-18 05:18:13 UTC
Created attachment 58536 [details]
Comment 2 Jan Pokorsky 2008-03-18 10:58:49 UTC
Reassigning to java/j2seproject that implements the generate javadoc action.
Comment 3 Tomas Zezula 2008-03-25 20:26:55 UTC
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:
According to it seems that the behavior differs depending on FS type.