Bug 130357 - I18N - mac - won't generate javadoc if project name or path has multibyte
I18N - mac - won't generate javadoc if project name or path has multibyte
Status: RESOLVED WONTFIX
Product: java
Classification: Unclassified
Component: Project
6.x
Sun Mac OS X
: P2 (vote)
: 6.x
Assigned To: Tomas Zezula
issues@java
: I18N, RELNOTE
Depends on:
Blocks:
  Show dependency treegraph
 
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
:


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

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

106944
108321 
108322
108323
Comment 1 Ken Frank 2008-03-18 05:18:13 UTC
Created attachment 58536 [details]
image
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: 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.




By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo