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.
using ja locale on solaris, j2se desktop app project - the default project encoding is utf-8 although user can use characters from the locale they are in and do not need to change project default encoding to do so. create j2se desktop application project with mbyte in its name and a class with mbyte in its name. choose to create java doc - there are syntax errors related to encoding - the errors are in japanese since javadoc error msgs have been translated to japanese, but the clue is in the words EUC_JP_SOLARIS see attached gif of output window errors - the gif is from the same bug on j2se project but the error msgs are the same. now change the project encoding property to euc-jp, which is the default encoding of solaris ja locale, and create another java class with mbyte in its name. now choose to create javadoc - there are no syntax errors associated with this newly created file, but still errors on the previous file that was created when project encoding was utf-8 NOTE - see 106944 for more information and about solution - that one is on j2se project.
Created attachment 44479 [details] image
According to my understanding, after issue 107083 is fixed we can fix this by updating the project.properties file according to the latest from j2se project generator. See also issue 106944. Should fix application templates in app framework and probably also also the GUI examples in usersguide (though it has little sense to generate javadoc for).
I've updated the project templates according to issue 106944.
The warnings are not present anymore, but the javadoc as it appears in browser shows incorrect multibyte since the encoding set for browser is iso-8859-1 instead of utf-8, which is the project encoding. the j2se project does set the encoding in browser corrrectly - should there be separate issue on this for desktop project ? (i am using 0630 build; this fix was in it, but is there additional fix related that might not have been in it ?)
The java desktop project is supposed to behave the same way as normal java project. Can you describe the exact steps to reproduce?
I dont know if its related to the fix of 106944 or other things, but now the javadoc that was just generated does not bring up a new browser window as it did before. is there an option about that ? or is it something indicated in the code for each project ? thus I cant verify about this yet, since when it brings up browser itself, it replaces the mbyte characters in the path with hex chars, and thus this works around mozilla bug of not being able to browse to path that has actual mbyte. ken.frank@sun.com
I've tried with UTF-8 encoding set on project and used mbyte in a method name and its javadoc. The result is same for standard java project as well as java "desktop" project - it shows properly if I set the browser to UTF-8 encoding manually, otherwise not. The generated files does not seem to have any encoding information included. So I think this is a separate issue of javadoc generation, not specific to the "java desktop application" projects. As for displaying the javadoc after generating, I don't know. Perhaps it was removed for 6.0. Does not seem to be related to the encoding issues.
who handles javadoc in general ? I need to find out about how it invokes the browser after generate javadoc, so I can verify it and why it not always invoke the browser - but javadoc page at nb site does not have members list. Thanks ken.frank@sun.com
The javadoc is covered by several modules: 1) The build of javadoc is handled by the project system + ant + javadoc tool. The project system is responsible for passing correct options to the ant's javadoc task which finally calls the jdk javadoc tool. There was a fix covering encoding, the project system now passes encoding option to the ant's javadoc task. 2) Opening of the browser is done by the browser integration module. 3) Javadoc search in the IDE is provided by the special javadoc module.
v