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 - javadoc not found on solaris, maybe other platforms, in certain cases wrt multibyte | ||
---|---|---|---|
Product: | java | Reporter: | Ken Frank <kfrank> |
Component: | Project | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jf4jbug, jpokorsky, masaki, mmirilovic, tmysik |
Priority: | P3 | Keywords: | I18N, RELNOTE |
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
case 1 - utf8 pronect encoding
euc-jp project encoding |
Description
Ken Frank
2007-10-09 03:02:04 UTC
Created attachment 50458 [details]
case 1 - utf8 pronect encoding
Created attachment 50459 [details]
euc-jp project encoding
on windows, using firefox, case 1 is ok, case 2 is not, same kind of problems as described below IE is ok for both cases. ken.frank@sun.com IMO it is caused by misconfigured javadoc target. It should set -charset, -encoding (-docencoding) options properly. Reassigning to java/j2seproject. Ken, try to add proper options to the project customizer Build/Documenting/Additional options e.g. -encoding UTF-8 -charset UTF-8 -docencoding UTF-8. It works to me then. Jan, 1 question and 1 comment - comment - user should not need to add encoding option to get this to work ok IMO; since there is now project/file encoding things, it seems that thats all user should need to do; en users don't have to do it so users in other locales should not also. And in past I don't think that was a requirement for javadoc. - question - is separate issue needed for all project types/components in which javadoc can be generated or is this one enough ? ken.frank@sun.com also, issues were filed on samples to be regenerated to be able to use the new feq things; some of these have been done; some not yet; would those done need to be regeerated again if this is fixed ? ken.frank@sun.com Ken, I have asked you to add options to verify it works even for you. The fix should patch build-imp.xml the same way. I did not close the bug saying a workaround exists. I agree it should work automatically. As for the 'all project types' question it has to be answered by j2seproject guys. Checking in org/netbeans/modules/java/j2seproject/resources/build-impl.xsl; /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl,v <-- build-impl.xsl new revision: 1.104; previous revision: 1.103 done Fix only for j2seproject, fixes also j2seproject samples. I think it's good thing that we specify the default encoding of javadoc and charset tag in generated javadoc by default. but I have one question - can user overwrite the such encoding options when users specify own options into "Additional Javadoc Options"? If someone wants to generate javadoc in different encoding, the user will customize the option. Will this work? Anyway, I'll try when new build ready. reopening its ok in ja locale on solaris, using utf-8 default project encoding. However, having a new project with euc-jp encoding, it still does not work as per original issue, it can't find the path to the project since project name and also nb project dir has mbyte in its name. Even using the suggested javadoc options mentioned below using EUC-JP as the value does not help. ken.frank@sun.com You don't need to add these options, it's part of the fix. It seems as a file system encoding vs content encoding problem, probably nothing we can fix. The problem is that the part of the URL is UTF-8 and part is EUC-JP, the javadoc tool stores the URL in the encoding it generates the web page, but the right way is to generate the text in requested encoding (in your case EUC-JP) and urls in UTF-8. The only workaround of this problem is that we force that the javadoc will be always generated in UTF-8. Is it acceptable? I think the problem with using utf-8 is that the opposite problem can happen, there will still be 2 encodings active and thus instead of path/project dir not found, it can be that the pkg or class file (that is named with non ascii) will not be found (or visa versa). ken.frank@sun.com OK, in this case it's a WONTFIX, since it's not fixable in the IDE. I added relnote keyword so perhaps this can be mentioned, and possible workaround might be to have browser go directly to the needed pages, though even that might not work since still multiple encodings in this case. ken.frank@sun.com But I still think that UTF-8 encoded javadoc is much better since probably all OS are having UTF-8 encoded file system, the problem will disappear for 99% os users. It still might be more common for users to use non utf-8, since windows, as least for ja and zh, does not have locales/reg settings that have utf-8 as their default encoding. and even those running on unix, that does have utf8 locales, might need to use legacy encodings (like are found in solaris ja locale). but if its about using utf-8 as the project encoding in nb, and the fix is for that case, then I agree that most users will use the default encoding of utf-8. ken.frank@sun.com It would be nice if someone who has Japanese windows can try it. On Solaris I cannot say since the file system is UTF-8. I tried the latest daily build on Japanese Windows. In both cases windows-31j and UTF-8 project encoding, it's working fine. (If I use multibytes in project name and project path, the problem appears. But let's ignore such cases.) I agree with Tomas, let's use UTF-8 encoding for javadoc encoding, I believe it can help more cases e.g. - Create NB project in EUC-JP encoding on Windows Japanese - Create NB project in windows-31j encoding on Solaris EUC locale These are not common case but with current implementation, it's not working when class and package name include multibyte. If we could generate javadoc always in UTF-8, I think it will work. OK, I will change it to generate UTF-8 javadoc. Changed to generate javadoc's HTML pages in UTF-8. Checking in org/netbeans/modules/java/j2seproject/resources/build-impl.xsl; /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl,v <-- build-impl.xsl new revision: 1.106; previous revision: 1.105 done as to comment (If I use multibytes in project name and project path, the problem appears. But let's ignore such cases.) - but they are valid cases also. I am ok with the fix as to utf-8, but needed to clarify about that point. ken.frank@sun.com its a long issue - Tomas, could you summarize the fix; and what cannot be expected to work now as to if user has non ascii in some project names or paths while using either utf-8 or some other project encodings ? Thanks - Ken ken.frank@sun.com As far as I remember the fix works in the following way: 1) The javadoc reads the source in the project's encoding - set in project customizer 2) The javadoc generates HTML pages always in the UTF-8 encoding - needed by browsers which expect URL encoded in UTF-8 but javadoc generates the URL in the same encoding as the HTML which caused that links didn't work. When the project is set up correctly - all source roots are in the project encoding, the javadoc should be generated correctly in the UTF-8. Tomas, I want to finally verify this one, but first a summary question: 1. from Tomas comments As far as I remember the fix works in the following way: 1) The javadoc reads the source in the project's encoding - set in project customizer 2) The javadoc generates HTML pages always in the UTF-8 encoding - needed by browsers which expect URL encoded in UTF-8 but javadoc generates the URL in the same encoding as the HTML which caused that links didn't work. When the project is set up correctly - all source roots are in the project encoding, the javadoc should be generated correctly in the UTF-8. 2. from Ken's questions: but I'd seen that if user used another encoding for project, it would not work: The problem is that the part of the URL is UTF-8 and part is EUC-JP, the javadoc tool stores the URL in the encoding it generates the web page, but the right way is to generate the text in requested encoding (in your case EUC-JP) and urls in UTF-8. The only workaround of this problem is that we force that the javadoc will be always generated in UTF-8. Is it acceptable? ------- Additional comments from kfrank Tue Oct 16 15:04:51 +0000 2007 ------- I think the problem with using utf-8 is that the opposite problem can happen, there will still be 2 encodings active and thus instead of path/project dir not found, it can be that the pkg or class file (that is named with non ascii) will not be found (or visa versa). 3. and Tomas replie: ------- Additional comments from tzezula Tue Oct 16 15:20:18 +0000 2007 ------- OK, in this case it's a WONTFIX, since it's not fixable in the IDE. ===> thus the fix is only if project using utf-8 project encoding ? (and we are saying wontfix for other cases of it) We can still verify it, just want to be clear. ken.frank@sun.com Hi Ken, the final state is: Sources are read in the project encoding and javadoc is always generated in UTF-8. This shouldn't be problem since it's a html, so it's contains an encoding. The problem 3. (wontfix) can happen when filesystem is not able to store UTF-8 file names or resolve them, but it's up to the user to fix such kind of problems. |