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 13859 - I18N - Can not Display japanese file name on Manifest tab
Summary: I18N - Can not Display japanese file name on Manifest tab
Status: CLOSED WONTFIX
Alias: None
Product: obsolete
Classification: Unclassified
Component: jarpackager (show other bugs)
Version: -FFJ-
Hardware: Sun Solaris
: P2 blocker (vote)
Assignee: issues@obsolete
URL:
Keywords: I18N
: 13287 33857 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-07-23 21:08 UTC by Ken Frank
Modified: 2003-07-01 10:02 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2001-07-23 21:08:47 UTC
(closing the bugtraq bug and entering it in
issuezilla)

Tested Environment: 
    Forte for Java, EE v.3.0 (Build 010501_1)
    Solaris 8 u2 (ja/EUC)
    JDK 1.3.0

How to Reproduce: 
    1. Choose "File" on main menu -> "New", then opened "New From 
Template
       Wizard". In the Step 1 dialog, expand "Jar Packager" nodes 
and select 
       "Jar Contents". Click Next button. 
    2. In the Step 2 dialog (Choose target), input Japanese target
 name in
       "Name:" field. Click Next button.
    3. In the Step 3 dialog (JAR Contents), add some files as Jar 
contents. 
       Click Next button.
    4. In the Step 4 dialog (JAR Location), the Japanese target na
me can be
       displayed correctly. Click Next button. 
    5. In the Step 5 dialog (JAR Manifest), click "Generate" butto
n. 
    6. Japanese .jarContent filename is displayed in Manifest Tab 
pane. 
    7. Click Finish button. Created JAR file.

Issue: 
    At the step 6 above, Japanese .jarContent filename is garbage.
 
    See attached manifestTab.gif. 
    However Japanese target name can be displayed on Explorer corr
ectly. 
    See attached Explorer.gif also.
Comment 1 Mike Schilling 2001-08-29 21:47:54 UTC
*** Issue 13287 has been marked as a duplicate of this issue. ***
Comment 2 Mike Schilling 2001-08-29 22:06:35 UTC
This is a consequence of JDK bug 4260472, entered by Jesse Glick in August of 1999!  I 
encourage anyone who cares about this to go to 
http://developer.java.sun.com/developer/bugParade/bugs/4260472.html and vote for this 
bug to be fixed.

The jar packager never writes directly to the Manifest pane display.  Instead, it adds 
attributes to the Manifest object (classes Manifest and Attributes in 
package java.util.jar), and lets the Manifest object format the output.  Unfortunately, 
this class (along with the Atributes class) cannot handle doublebyte characters.  In 
fact, it simply chops off the top byte, leading to the garbage described above.  

Note that there is no good way to work around this JDK bug.  If the jar packager wrote 
directly to the display, the doublebyte characters would still be corrupted when the 
Manifest was serialized to the .jarContents file.  Even supposing the doublebyte 
characters could be written correctly to the jar file, the running java application, 
using the Manifest object to read the jar's manifest, would see them as garbage (each 
byte of a doublebyte character would become part of a separate Java character.)  This 
needs to be fixed in the JDK, ideally by treating a manifest as UTF-8.
Comment 3 Mike Schilling 2001-09-06 01:06:48 UTC
Not fixed, but addressed.  Until the JDK resolves this issue, the IDE will not allow 
double-byte characters from being inserted into manifests, either by typing them in or 
by loading a file which contains them. 
Comment 4 hiroshiy 2003-05-23 11:44:58 UTC
*** Issue 33857 has been marked as a duplicate of this issue. ***
Comment 5 Quality Engineering 2003-07-01 09:57:48 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.
Comment 6 Quality Engineering 2003-07-01 10:01:27 UTC
Resolved for 3.4 or earlier, no new info since then -> closing.
Comment 7 Quality Engineering 2003-07-01 10:02:27 UTC
Resolved for 3.4 or earlier, no new info since then -> closing.