FULL PRODUCT VERSION :
PC:
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)

Solaris
- equivalent build/install : JRE 1.5.0_04

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]
SunOS wcarsx05 5.9 Generic_117171-02 sun4u sparc SUNW,Ultra-60

A DESCRIPTION OF THE PROBLEM :
Following loadbuild process used:
===========================
- Java Compile, Jar, Pack200 occurs on a Solaris machine, using Ant 1.6.2 and JDK 1.5.0_04. pack200 using -g option to product .pack files
- Solaris Installer created using InstallAnywhere, JRE 1.5.0_04, and the .jar files.
- PC Installers created using InstallAnywhere, JRE 1.5.0_04, and the .pack files.

Runtime without .pack files ok:
========================
Solaris Installer installs successfully (own code and jre). The java program runs without problems.

Runtime using unpacked .pack files has corrupted class files:
================================================
PC Installer installs (this will unpack200 the .pack files to .jar files) sus. During runtime the java program will dies with the following error:

Exception in thread "ThreadName" java.lang.VerifyError: (class: someClass, method: someMethod signature: ()V) Must call initializers using invokespecial

Points to note:
===========
 - PC Install uses Solaris packed files, but unpacks on the PC. This is
not the problem. Using the program installation on Solaris, the affected jar was packed and unpacked locally, and then replaced in the class path. It had the same error on the Solaris machine.

 - Not all loadbuilds/installs run into this problem - the corrupted class
file from the pack200/unpack200 tool does not appear to be a
consistent class. For one loadbuild process its is sticking to one file (for now), for a different loadbuild process it was another class file entirely.

 - Used javap to disassemble the class file from the original jar, and the unpacked jar. The someMethod contents from the unpacked jar only resembled the original for the
   - method name
   - signature
   - code: stack/locals/argsize values
   - and the first 2 disassembled lines....
    .... and then it got quite depressing as the method references other code that it was not using.

 - The .pack files were created using the Pack200Task for Ant and by using the pack200 tool supplied in the JDK.
  > pack200 -g something.jar.pack something.jar

 - The unpack200 tool was used directly by the installer from the os-specific jre brought in with the installer.
 > unpack200 -r something.jar.pack something.jar

Another note, when testing directly on Solaris, pack200 and unpack200 were run 'by hand'. In that case, the unpack200 command did not use the -r option.








 

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See description.

Note the loadbuild was originally using 1.5.0_02, with the installer
using 1.5.0_03. This problem was not seen then, but because it
appears that random files are being corrupted and not all code is
being regressed, that this problem could still exist in these releases.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Working java program on the PC!

This problem has been visible in our PC loads for the past 4 builds.


ACTUAL -
  Program runs and then dies with the following error:

Exception in thread "SomeThread" java.lang.VerifyError: (class: SomeClass, method: someMethod signature: ()V) Must call initializers using invokespecial

In all cases the "Must call initializers using invokespecial" has been
seen.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
See actual result.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Without a fix or workaround or explanation of what could be
the cause of this problem, we'd have to drop the use of pack200 from
the installers, and would recommend not using it in code either.