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.
When x86 installer is run in ja_JP.PCK and ja_JP.UTF-8 locales, Japanese characters in the terminal window look garbages. # ./NetBeansIDE-release351-200307102351-ML-JA-solarisX86.bin InstallShield Wizard InstallShield Wizard ==garbage=== ... Java(tm) === garbage ===... ............. This problem might be known problem of InstallSheild. Also, this might be the same issue as 25434. The sparc installer does not have this problem and behaviors are as follows. run in ja Ja mesages appear run in ja_JP.PCK Eng message appear run in ja_JP.UTF-8 Eng message appear I think x86 installer should be the same behaviors as sparc installer. I think this needs to be fixed in ML-JA NB3.5.1, so could you please fix this asap? ML-JA RC2 build is 7/14, but it is ok that build date will be postponed to fix this (2 or 3 days).
Created attachment 10947 [details] snapshot of terminal in ja_JP.UTF-8 locale
It should be problem of InstallShield. We replaced our launchers with patched launchers form S1S and its all what we can do. Please try whether S1S installer behaves the same way or not.
I asked RE people to ensure that there are correct patched launchers on build machine. Please try build 200307112351. I'll try to test it even though it is saturday.
Unfortunatelly it looks here is not any computer with SolarisX86 on it. So please try the last build and also check beahvior of S1S installer, thanks.
We tested x86 installers in ML-JA build 200307112351 and 200307122351, but this problem still occured. In Nevada, x86 installer does not exist and we use 1s5se-sol-x86-ml.jar, so messages in the terminal window do not appear. Nevada sparc installer and NB3.5.1 sparc installer does not have this problem. Could you please investigate if InstallSheild patch is applied for x86 installer?
Hello Yuko, we're sorry, but QA doesn't see it as a showstopper: - it is a bug at InstallShield. Thus we must ask InstallSheild for the patch for Solaris-Intel executor. BTW: We're already got patches for linux and Sparc. Could you please confirm, that for Japanese Linux and Solaris-Sparc problem is over? - also because SunOne studio doesn't support Sol-x86 installers and thus you can't see this bug there. - IMHO, it is possible install the product with this bug. We see problem only when it is not possible install the product from some reasons (like can't find JDK, no space on HD) In this case it is impossible to detect why and what is a problem.... - It's too late when bug was reported... and the release has its schedule and can't be delayed.... till now nobody found it as a problem and now 2-3 days before release it is:-|
CC'ing Ken
CCing Patrick.
Short summary of current state: 1)I asked Chau to ask InstallShield to provide patched launcher for SolarisX86 2)QA tests whether this problem occures also in Nevada installer 3)Proposed solutions:
- use patched launcher and rebuild (depends on InstallShield) - waive issue - provide jar installer instead of binary one ( I think that Nevada provides only jar installer for SolarisX86.jar for unknow reason)
I think that providing jar installer could help us to avoid problems with jvm search in binary installers.
> 2)QA tests whether this problem occures also in Nevada installer So far we've got a few emails (but personaly I feel litle bit confused by results in those emails). It'd be better if Japanesse QA guys could provide feedback directly here... ...waiting for their feetback....
This is our thought. - Chau is working with IS to fix this problem, so we wait the answer if this can be fixed by the end of this week. - If this problem cannot be fixed, we would like to release .jar installer instead of .bin installer.
Richard re-send me some testing classes, so I'll try to run them on some x86 Solaris... BTW: I'm changing the Platform from Sun -> PC I suppose that the problem is realy platform specific and occures only on Solaris-Intel. If not, please set propers value of: Platform & OS thanks
I did several runs of provided testool, and here are the details & outputs: =============================================================== First Machine hasn't got installed JA locale (and don't know anything about patches installed there, etc) see attachements: - en-Sol9x86-nopatches.out - ja-Sol9x86-nopatches.out The second Solaris9 x86 was c.5 days old internal release of Solaris 9 with the newest packages&patches and with installed all available locals. But when I login with any Japanesse locale, the machine get terribly slow and often crashed my terminal. for outputs see attachements: - ja-Sol9x86-patches.out (loged to X with C-posix locale) - ja_JP.UTF-8-Sol9x86-patches.out (loged to X with JA UTF) but JVM always crashed... so I gave it up:-(
Created attachment 11025 [details] X C-posix locale, and executed: $>java -cp . I18nSample WizardXResources en
Created attachment 11026 [details] X C-posix locale, and executed: $>java -cp . I18nSample WizardXResources ja
Created attachment 11027 [details] X C-posix locale, and executed: $>java -cp . I18nSample WizardXResources ja
Created attachment 11028 [details] X ja-UTF locale, and executed: $>java -cp . I18nSample WizardXResources ja_JP.UTF-8
For Chinese UTF-8 locale, the terminal message is also garbage.
Please add the I18N keyword to all I18N-related bugs.
FYI: look at issue #35077 which is reported again imposibility install ide from jar installers on Solx86
As stated before, this is an installshield bug. I've tried to reproduce this using the ismp5 installers. The problem appears to still exist. Daniel, can you verify this. My Japanese isn't very good!
George, I used standard ISMP5 installation for Solaris SPARC. There's absolutely no additional patch to original install on production build machine. Does the ISMP 5 still need some extra patch to make it working for solX86?
We are using ismp 5.0 with no service packs. The latest is service pack 3. This would need to be implemented on our side and evaluated before we could upgrade permanently. I'd also need to research the installshield fixes in the service packs to see if this bug has even been fixed. This won't get fixed for Beta release of 3.6 as there is a lot to do and not enough time.
The L10N team has tested a couple of installers that I created using ismp 5.0 and 5.0 sp3. They have stated to me that the issue has been resolved with the service pack 3. We will try to upgrade to service pack 3.
The ja issue is resolved in ismp5.0 sp3 but the zh issue has not. I don'tknow if InstallShield knows about this problem with zh, so I will contact them with the info. Will attempt to install sp3 for the ml release, where it is needed for ja.
Waiver approved.
I have since found out that a patch was created for ISMP 5.0. This was installed for 3.6 ml build. Issue 41998 also raises this issue along with another so I will close this issue as fixed and update the other.
verified, then closed.