1 <?xml version="1.0" encoding="utf-8"?> 2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 3 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 4 <html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang= 5 "en-US"> 6 <head> 7 <title>Pack200: Packed Class Archive Specification</title> 8 </head> 9 <body> 10 11 <h1>Pack200: A Packed Class Deployment Format For Java 12 Applications</h1> 13 14 <p><em>BASE VERSION:</em> <a href= 15 "http://docs.oracle.com/javase/6/docs/technotes/guides/pack200/pack-spec.html"> 16 http://docs.oracle.com/javase/6/docs/technotes/guides/pack200/pack-spec.html</a></p> 17 18 <h2>Contents</h2> 19 <!-- &TOC; --> 20 <ul> 21 <li><a href="#tocIntrod">1. Introduction</a></li> 22 <li><a href="#tocArcInp">2. Archive Inputs</a></li> 23 <li><a href="#tocArFiStSu">3. Archive File Structure 24 Summary</a></li> 25 <li><a href="#tocInInEn">4. Introduction to Integer 26 Encodings</a></li> 27 <li style="list-style: none; display: inline"> 28 <ul> 29 <li><a href="#tocInEnSc">4.1. Integer Encoding Schema</a></li> 30 </ul> 31 </li> 32 <li><a href="#tocBanDef">5. Band Definitions</a></li> 33 <li style="list-style: none; display: inline"> 34 <ul> 35 <li><a href="#tocArcSeg">5.1. Archive Segmentation</a></li> 36 <li><a href="#tocArcHea">5.2. Archive Header</a></li> 37 <li style="list-style: none; display: inline"> 38 <ul> 39 <li><a href="#tocArOpFiPr">5.2.1. Archive Options and File 40 Properties</a></li> 41 <li><a href="#tocArEnCoClFo">5.2.2. Archive Entity Counts and Class 42 Format</a></li> 43 </ul> 44 </li> 45 <li><a href="#tocConPoo">5.3. Constant Pools</a></li> 46 <li style="list-style: none; display: inline"> 47 <ul> 48 <li><a href="#tocScaCon">5.3.1. Scalar Constants</a></li> 49 <li><a href="#tocUtfCon">5.3.2. Utf8 Constants</a></li> 50 <li><a href="#tocTypSig">5.3.3. Type Signatures</a></li> 51 <li><a href="#tocTupCon">5.3.4. Tuple Constants</a></li> 52 <li><a href="#tocExtCon">5.3.5. Extra Constants</a></li> 53 </ul> 54 </li> 55 <li><a href="#tocFilAtt">5.4. File Attributes</a></li> 56 <li><a href="#tocFlaAtt">5.5. Flags and Attributes</a></li> 57 <li style="list-style: none; display: inline"> 58 <ul> 59 <li><a href="#tocAsFlBiAt">5.5.1. Assignment of Flag Bits to 60 Attributes</a></li> 61 <li><a href="#tocAtLaDe">5.5.2. Attribute Layout 62 Definitions</a></li> 63 <li><a href="#tocRecLay">5.5.3. Recursive Layouts</a></li> 64 <li><a href="#tocDeAtLa">5.5.4. Default Attribute Layouts</a></li> 65 <li><a href="#tocStMaLa">5.5.5. Stack Map Layouts</a></li> 66 <li><a href="#tocMetLay">5.5.6. Metadata Layouts</a></li> 67 <li><a href="#tocUnLaUs">5.5.7. Unusual Layout Usages</a></li> 68 </ul> 69 </li> 70 <li><a href="#tocSoFiAb">5.6. Source File Abbreviation</a></li> 71 <li><a href="#tocNesCla">5.7. Nested Classes</a></li> 72 <li><a href="#tocClaSch">5.8. Class Schema</a></li> 73 <li><a href="#tocAttBan">5.9. Attribute Bands</a></li> 74 <li style="list-style: none; display: inline"> 75 <ul> 76 <li><a href="#tocMetTra">5.9.1. Metadata Transmission</a></li> 77 </ul> 78 </li> 79 <li><a href="#tocBytIns">5.10. Bytecode Instructions</a></li> 80 </ul> 81 </li> 82 <li><a href="#tocSpBaCo">6. Specification of Band Coding</a></li> 83 <li style="list-style: none; display: inline"> 84 <ul> 85 <li><a href="#tocEnSmWhNu">6.1. Encoding of Small Whole 86 Numbers</a></li> 87 <li style="list-style: none; display: inline"> 88 <ul> 89 <li><a href="#tocScMuCo">6.1.1. Scheme of Multiple Codings</a></li> 90 <li><a href="#tocDeEnBySe">6.1.2. Definition of Encoding Byte 91 Sequences</a></li> 92 <li><a href="#tocDeDeWhNuVa">6.1.3. Definition of Decoded Whole 93 Number Values</a></li> 94 </ul> 95 </li> 96 <li><a href="#tocEnSiIn">6.2. Encoding of Signed Integers</a></li> 97 <li style="list-style: none; display: inline"> 98 <ul> 99 <li><a href="#tocFuDiSiCo">6.2.1. Further Discussion of Sign 100 Conversion</a></li> 101 </ul> 102 </li> 103 <li><a href="#tocAttCod">6.3. Attributes of Codings</a></li> 104 <li><a href="#tocEnCoSe">6.4. Encoding of Correlated 105 Sequences</a></li> 106 <li><a href="#tocEnUnVa">6.5. Encodings of Uncorrelated 107 Values</a></li> 108 <li style="list-style: none; display: inline"> 109 <ul> 110 <li><a href="#tocTabFav">6.5.1. Table of Favorites</a></li> 111 <li><a href="#tocSeqTok">6.5.2. Sequence of Tokens</a></li> 112 <li><a href="#tocSeUnVa">6.5.3. Sequence of Unfavored 113 Values</a></li> 114 </ul> 115 </li> 116 <li><a href="#tocAdaEnc">6.6. Adaptive Encodings</a></li> 117 <li><a href="#tocMetCod">6.7. Meta-Coding</a></li> 118 <li style="list-style: none; display: inline"> 119 <ul> 120 <li><a href="#tocCoSpSt">6.7.1. Coding Specifier Structure</a></li> 121 <li><a href="#tocCoSpSe">6.7.2. Coding Specifier Semantics</a></li> 122 <li><a href="#tocCoSpMeEn">6.7.3. Coding Specifier 123 Meta-Encoding</a></li> 124 <li><a href="#tocCanCod">6.7.4. Canonical BHSD Codings</a></li> 125 </ul> 126 </li> 127 </ul> 128 </li> 129 <li><a href="#tocStDeOu">7. Stability of Decompressor 130 Output</a></li> 131 <li style="list-style: none; display: inline"> 132 <ul> 133 <li><a href="#tocOrAtLi">7.1. Ordering of Attribute Lists</a></li> 134 <li><a href="#tocOrCoPo">7.2. Ordering of Constant Pools</a></li> 135 </ul> 136 </li> 137 <li><a href="#tocAppend">8. Appendixes</a></li> 138 <li style="list-style: none; display: inline"> 139 <ul> 140 <li><a href="#tocApLiBa">8.1. Appendix: List of Bands</a></li> 141 <li><a href="#tocApPsCoIl">8.2. Appendix: Pseudo-Code 142 Illustrations</a></li> 143 <li style="list-style: none; display: inline"> 144 <ul> 145 <li><a href="#tocReUtCoPo">8.2.1. Representation of 146 <tt>cp_Utf8</tt> Constant Pool</a></li> 147 <li><a href="#tocReSiCoPo">8.2.2. Representation of 148 <tt>cp_Signature</tt> Constant Pool</a></li> 149 <li><a href="#tocReByOf">8.2.3. Representation of Byte 150 Offsets</a></li> 151 <li><a href="#tocRePrNeClNa">8.2.4. Representation of Predictable 152 Nested Class Names</a></li> 153 </ul> 154 </li> 155 <li><a href="#tocAppDes">8.3. Appendix: Design FAQ</a></li> 156 <li style="list-style: none; display: inline"> 157 <ul> 158 <li><a href="#tocGenQue">8.3.1. General Questions</a></li> 159 </ul> 160 </li> 161 </ul> 162 </li> 163 </ul> 164 <!-- 165 --> 166 <h2>Revision History</h2> 167 <h3>Changes made to support JSR-308 Mar-2013</h3> 168 <ul> 169 <li>Added RuntimeVisibleTypeAnnotation and RuntimeInvisibleTypeAnnotation.</li> 170 </ul> 171 <h3>Changes made to support JSR-335 Feb-2013</h3> 172 <ul> 173 <li>Added two new pseudo-instructions "invokespecial_int" and 174 "invokestatic_int" referencing cp_Imethod operands.</li> 175 </ul> 176 <h3>MethodParameters Flag changed Feb-2013</h3> 177 <ul> 178 <li>Changed flag from u4 to u2</li> 179 </ul> 180 <h3>Changes made to support MethodParameters Dec-2012</h3> 181 <ul> 182 <li>Increment the version number from 170.0 to 171.0</li> 183 <li>Added attribute structure</li> 184 </ul> 185 <h3>Changes made for JSR 292 support Aug-2011</h3> 186 <ul> 187 <li>Bump the pack200 file format version number from 160.* to 188 170.0</li> 189 <li>Add optional cp_extra_counts to the archive header.</li> 190 <li>Add 4 extra constant pools: cp_MethodHandle, cp_MethodType, 191 cp_BootstrapMethod, cp_InvokeDynamic.</li> 192 <li>Defined the combined constant pool cp_AnyMember, comprising 193 cp_{Field,Method,Imethod}.</li> 194 <li>Defined the combined constant pool cp_LoadableValue, comprising 195 valid ldc operands.</li> 196 <li>Add new attribute layout codes for new constants: KM, KT, RY, 197 RB.</li> 198 <li>Add combined layout codes KL (any ldc-able value) and RN 199 (AnyMember), supplementing RQ.</li> 200 <li>Change the pseudo-instruction name "aldc" to "sldc", and add 201 "qldc".</li> 202 </ul> 203 <h3>Changes made for MR #1 01-Jun-2005</h3> 204 <ul> 205 <li>Adjust StackMapTable based on JSR-202 changes.</li> 206 <li>Bump the pack200 file format version number from 160.0 to 207 160.1</li> 208 <li>Clarify inconsistent tie-breaker rule in centrality 209 comparisons.</li> 210 </ul> 211 <h3>Changes made for MR #1 20-Apr-2005</h3> 212 <ul> 213 <li>Reinstate StackMap as StackMapTable JSR-202.</li> 214 </ul> 215 <!-- BEGIN CODE FOLD == 216 <h3>Changes made for PFD #4</h3> 217 <ul> 218 <li>Clarify primary vs. secondary band encodings. 219 <li>Clarify uniqueness of the empty string in cp_String. 220 <li>Fix some typos and minor errors in explanatory text. 221 <li>Remove "dot notation" for class file parts. 222 <li>Rename ClassFile_version to file_version. 223 <li>Explain rationale for 'SB' layout. 224 <li>Add examples of 'P', 'PO', and 'O' layout element encoding. (JK) 225 <li>Add priority list for layout element codings. (JK) 226 <li>Clarify priority of SIGNED5 for 'SB' layouts. 227 <li>Add FAQ about JEFF. 228 <li>Incorporate corrections and comments from EG 229 (Joel Kamentz 7/27,28). 230 </ul> 231 <h3>Changes made for PFD #3</h3> 232 <ul> 233 <li>Add LocalVariableTypeTable, same layout as LocalVariableTable. 234 <li>Bump package version number to 150.7 from 150.6. 235 <li>Clarify explanatory text where it conflicts with recent metadata changes. 236 <li>Comment out "Note To Reviewers". 237 </ul> 238 <h3>Changes made for PFD #2</h3> 239 <ul> 240 <li>Change all metadata references to classes from RCH or RUH to RSH. 241 <li>Bump package version number to 150.6 from 150.5. 242 </ul> 243 <h3>Changes made on Mar 25 post public review</h3> 244 <ul> 245 <li>Minor corrections from Public Review feedback. 246 <li>Moved pseudo-code to the Appendix. 247 </ul> 248 <h3>Changes made before public review 3Q2003</h3> 249 <ul> 250 <li>Bump package version number to 150.5 from 150.4. 251 <li>Simplify size limit for constant pools. 252 <li>Compress SourceFile ad hoc: ClassName.java transmits as zero. 253 <li>Make empty string implicitly defined in cp_Utf8. 254 <li>Make some header fields optional (cuts header size). 255 <li>Add an optional flag bits word for attributes (for future-proofing). 256 <li>Change band name "class_flags" to "class_flags_lo", etc. 257 <li>Require that optional #archive_size be exact when present. 258 <li>Adjust indexes (hence band order) of predefined attributes. 259 <li>Allow 'O' layouts to have signed variants (e.g., 'OSH'). 260 <li>Clarify transmission of NaN values in constant pool. 261 <li>Correct coding of cp_Descr_name/type. 262 <li>Correct format of EnclosingMethod. 263 <li>Make "call" layouts self-relative. 264 <li>Remove StackMap bands, for now. 265 <li>Remove generic attributes. (Not proven to be profitable.) 266 <li>Split predefined metadata attributes into (9) separate band groups. 267 </ul> 268 269 <h3>Changes in draft of September 5-6, 2003</h3> 270 <ul> 271 <li>Bump package version number to 150.4 from 150.1. 272 <li>Simplify and generalize IC name demangling rules. 273 <li>Provide for IC punctuation besides '$' (Tiger sometimes uses '#'). 274 <li>Allow customized local InnerClasses attributes (ic_local_bands). 275 <li>Do not let predefined attributes conflict with flags. (It's simpler.) 276 <li>Simplify handling of recursive calls; add "class_attr_calls", etc. 277 <li>Allow union cases in layouts to have several tags (1,2,3)[...]. 278 <li>Allow "generic" attribute layouts with a variable name (for metadata). 279 <li>Clarify 'pop' coding, that unused F elements are illegal. 280 <li>Rewrite CP ordering rules for decompressor, for better clarity. 281 </ul> 282 283 <h3>Changes in draft of July 30, 2003</h3> 284 <ul> 285 <li>Retitle. 286 <li>Incorporate corrections and comments from EG 287 (Joel Kamentz 7/21, Bill Pugh 7/09). 288 <li>Add optional #archive_size and #archive_next_count header 289 fields. 290 <li>Add CP element uniqueness requirement, to simplify output 291 determinism rules. 292 <li>Extend attribute layout spec. language to include unions, 293 recursion, and 'V' elements. 294 <li>Add placeholders for StackMap and metadata attributes. 295 <li>Add output determinism rules for synthesized constants 296 (e.g., implicit IC names), and specify ordering in the CP. 297 <li>Simplify discussion of code headers. 298 <li>Rename class_ClassFile_version_H1/H2 to 299 class_ClassFile_version_minor/major_H 300 <li>Add band-length pseudocode for code_flags and code_attr_count. 301 <li>Adjust and correct table of multi-byte instructions. 302 <li>Add implementation note on centrality comparison. 303 <li>Add constraint against zero-length runs in meta-coding. 304 <li>Adjust X/XB encoding to take a maximum of two bytes. 305 <li>Add constraints against crazy 'arb' meta-codings. 306 <li>Add predefined bands for Signature attributes. 307 <li>Remove some old inline questions to early reviewers. 308 <li>Remove some web lint and various typos. 309 </ul> 310 <h3>Changes in draft of July 11, 2003</h3> 311 <ul> 312 <li>Incorporate corrections and comments from EG 313 (Joel Kamentz 6/23 and 7/01, Bill Pugh 7/09). 314 <li>Integrate resource and class files, so we can 315 transmit a total ordering of JAR elements. 316 <li>Move file-related bands to the end of the archive. 317 <li>Add archive segmentation feature (cat x.pack y.pack > xy.pack). 318 <li>Add band lengths comments to the grammar. 319 <li>Ensure that all codings with Card>=2^32 have full 32-bit ranges, 320 for all S in [0..2]. 321 <li>Clarify 'pop' coding method; remove useless and hazy defaulting rule. 322 <li>Add a band summary appendix. 323 <li>Give flag bit 12 to Signature, not the less-frequent Deprecated. 324 <li>Change band name "resource" to "file" everywhere. 325 <li>Change band name "class_attr_layout" to "class_attr_indexes", etc. 326 <li>Change "compression_hint" to "deflate_hint". 327 <li>Bump package version number to 150.1 (following Tiger numbering). 328 <li>Add "no overflow" restriction to sum of all CP sizes. 329 <li>Clarify flexibility of cp_Signature constants (for GJC support). 330 <li>Clarify context-specificity of attribute logic. 331 <li>Clarify semantics of "release" and "redefinition" of attribute indexes. 332 <li>Fix various typos observed by reviewers. 333 </ul> 334 <h3>Changes in draft of June 20, 2003</h3> 335 <ul> 336 <li>Incorporated corrections and comments from EG (Joel Kamentz 6/06/03). 337 <li>Change "Archive" in title to more distinctive "Deployment". 338 <li>Mark scalar terminals in band grammar with leading "#". 339 <li>Mark band terminals in band grammar with leading "*". 340 <li>Small terminology changes (e.g., s/file_flags/file_options/). 341 <li>Add file_size_hi, for 64-bit-clean file sizes (!). 342 <li>Add code_flags, for bit-encoding of Code attribute indicators. 343 <li>Clarify interactions in the flag words between attribute 344 indicators and modifier bits. 345 <li>Clarify the process for releasing a predefined attribute bit. 346 <li>Adjust (reduce) assigned flag bits for predefined attributes. 347 <li>Note coming changes regarding file ordering. 348 <li>Define instruction boundaries used by renumber_bci. 349 <li>Clarify numbering of untyped references (cp_All). 350 <li>Clarify reconstruction of InnerClasses attributes. 351 <li>Clarify encoding and meaning of code_header bytes. 352 <li>Clarify encoding of BCIs in Code exception handlers. 353 <li>Add mechanism for escaping arbitrary bytes and refs into code. 354 <li>Add ('arb') for meta-coding arbitrary BHSD codes (EG suggestion). 355 <li>Clarify meta-coding of 'pop' and 'run' methods. 356 <li>Add section to define output stability (idempotence, for signable JARs). 357 <li>Small tweaks to spelling, diction, grammar, style. 358 <li>Adjusted meta-data format definitions to the JSR 175 format changes bug:5020908. 359 </ul> 360 361 <!== END CODE FOLD --> 362 <hr /> 363 <!-- &BODY; --> 364 <br /> 365 <a name="tocIntrod" id="tocIntrod"></a> 366 <h2>1. Introduction</h2> 367 This document specifies an archive format called "Pack200". It is 368 optimized for applications written in the Java programming language. Such applications are 369 usually delivered as collections of classes, sometimes with 370 associated resource files. 371 <p>This format allows any number (from one to hundreds of 372 thousands) of Java classes to be encoded by a compressor, 373 transmitted compactly in a single block of bytes, and decoded by a 374 decompressor into equivalent Java class files. Because it can also 375 represent class resources and other "side files", it can serve as 376 an alternative to the JAR archive for some deployment tasks, 377 notably downloading Java applications.</p> 378 <p>The Pack200 format can decrease the size of a Java application 379 by a factor of seven to nine, compared with an equivalent JAR 380 containing uncompressed ("stored") class files. By contrast, using 381 the zip DEFLATE algorithm integral to JAR and ZIP archives gains a 382 factor of two. The undocumented "crunch" mechanism, used to deploy 383 SDK downloads in the past, gains a corresponding factor of five to 384 six. Note that all these figures assume and incorporate the effects 385 of a post-pass with DEFLATE or a similar off-the-shelf compression 386 algorithm. (See <a href="https://www.ietf.org/rfc/rfc1951.txt">DEFLATE Compressed Data Format Specification</a> for more information.)</p> 387 <p>The main motivation for this format is to decrease disk and 388 bandwidth requirements for Java application packaging, 389 transmission, and delivery. An earlier version has been used to 390 package the downloads for Java 2 Standard Edition release 1.4.1 and 391 1.4.2 (code names "Hopper" and "Mantis").</p> 392 <p>This format is not intended for fast loading into a virtual 393 machine, and does not attempt to improve start-up speed or memory 394 footprint in running Java applications. The heavy engineering 395 requirements on a directly loadable file format would make optimal 396 compression impossible. The decompressor of an aggressively 397 compressed file will have a complex job to do, and must be allowed 398 memory and CPU time to do this job. We assume that Pack200 archives 399 will be unpacked on the same classes of machine that run Java SE 400 and J2EE applications.</p> 401 <p>This format is batch-oriented, optimized for packaging and 402 transmission of Java classes. It does not support random access of 403 individually stored classes. In order to emphasize the sequential 404 nature of this archive format, we will use the verb 405 <em>transmit</em>, rather than <em>store</em>, to refer to the 406 formatting of data produced by a compressor and accepted by a 407 decompressor.</p> 408 <p>This format does not attempt to duplicate work performed by 409 DEFLATE or other byte-oriented compression algorithms. Typically, 410 tools using Pack200 will further compress archives by storing them 411 in ZIP files or using some other compression technique. The 412 presence of such a post-pass compressor is an assumption made by 413 the design of Pack200.</p> 414 <p>This specification is complex, and may seen to some readers 415 needlessly complex. The design decisions reflected here have been 416 motivated by extensive testing and experimentation with actual Java 417 class files found in real products. An attempt to remove complexity 418 from this specification is likely also to remove measurably 419 significant compression efficiency.</p> 420 <a name="tocArcInp" id="tocArcInp"></a> 421 <h2>2. Archive Inputs</h2> 422 A Pack200 archive, like a JAR file, carries images of class files 423 and other ("resource") files arranged in a hierarchical directory 424 structure. 425 <p>No special compression or transformation is performed on any 426 file other than class files, other than (possibly) reordering them 427 by file type. The post-pass compressor is assumed to provide 428 adequate compression on those spans of the archive which carry 429 images of non-class files.</p> 430 <p>Classes are represented in a form which suppresses their 431 individual constant pools, in favor of a large constant pool that 432 serves the entire archive. Thus, when a class file is extracted 433 from a Pack200 archive, a new constant pool will be created for it, 434 and all constant pool references adjusted. This does not change the 435 semantics of the class, but it will generally modify the bitwise 436 image of the file, and perhaps even its size, as unused constant 437 pool entries are deleted.</p> 438 <p>Note that every class file must be fully parsed by the 439 compressor, so that all constant pool indexes may be found and 440 (later) renumbered. This requirement applies to any class, field, 441 method, or code attribute which refers to the constant. The Pack200 442 format supports a moderate range of attributes. A modest variety of 443 new attribute layouts may be declared to the 444 compressor, and the Pack200 format provides a place to transmit 445 such layouts for use by decompressors. See the section <a href="#layouts">Attribute Layout Definitions</a> for more information.</p> 446 <a name="tocArFiStSu" id="tocArFiStSu"></a> 447 <h2>3. Archive File Structure Summary</h2> 448 The archive file consists of a short <em>archive header</em>, 449 followed by a number of independent file sections called 450 <em>bands</em>. (There are about 100 of them; this number can 451 vary.) Each band transmits an array of small integers, called the 452 <em>elements</em> of the band. After the archive header, the 453 archive consists only of bands. 454 <p>Logically, a band is an implicitly sized array of 32-bit 455 unsigned integers. However, it is rare for a band to physically 456 require more than one or two bytes per element, since element 457 encodings are chosen to transmit the actual band values more 458 compactly.</p> 459 <p>A band has no fixed header, not even an indication of its size. 460 The count of band elements is deduced by the decompressor from the 461 contents of previous bands, or (ultimately) from the archive 462 header.</p> 463 <p>The elements of any given band have a common meaning and role. 464 For example, the names of all transmitted classes are in a single 465 band, while all the class field counts are in a different band. 466 Each band is transmitted as a contiguous segment of bytes within 467 the archive. This contiguity is the main reason that a Pack200 468 archive, while compact to begin with, is very compressible by 469 utilities like zip.</p> 470 <p>In some bands, each element helps describe one object. For 471 example, each class is associated with a count of fields, which is 472 given in the archive as a corresponding value in the 473 <tt>class_field_count</tt> band. In other bands, one object may be 474 described by a <em>run</em> of zero or more elements in a band. For 475 example, the interfaces implemented by a class are given in the 476 archive as a corresponding run of zero or more values in the 477 <tt>class_interface</tt> band; each such value is an index 478 referring to a single class.</p> 479 <p>A very few bands (less than 10) contain non-homogeneous bytes, 480 such as the images of resource files. These few are called <em>byte 481 bands</em>. Many of the bands contain references into the constant 482 pool. Some contain access modifier flags and related bits. One 483 band, called the <em>char band</em>, contains string characters in 484 a specially chosen encoding called "CHAR3" (somewhat akin to UTF8, 485 but not identical). The rest of the bands transmit integers with a 486 variety of other interpretations.</p> 487 <p>One of the integer bands (cp_Utf8_big_chars) carries the 488 characters of a single CONSTANT_Utf8 string selected for special 489 treatment. Uniquely, this band is repeated zero or more times, 490 depending on how many strings are selected for this special 491 treatment. (These specially-transmitted "big strings" are explained in the section 492 <a href="#big_string">Utf8 Constants</a>.)</p> 493 <p>Most bands have an easily understood function, such as 494 transmitting the number of methods in a class, or the name of a 495 field, or the operand of a "getfield" bytecode instruction.</p> 496 <p>Except for the special case of byte bands, a band is never 497 considered as a sized span of bytes, but rather as a counted series 498 of elements which are encoded integers. Since integer encodings are 499 typically variable-sized (when regarded as byte sequences), there 500 is no firm rule for deriving a band's byte size from its element 501 count. Indeed, finding the end of a band requires that it be parsed 502 byte-by-byte.</p> 503 <a name="tocInInEn" id="tocInInEn"></a> 504 <h2>4. Introduction to Integer Encodings</h2> 505 Each band uses one or more coding tactics to encode its elements as 506 sequences of bytes. (The post-pass compressor is expected to turn 507 these bytes into bit sequences, but its actions are not specified 508 by this document.) The Pack200 compressor is free to choose and 509 vary encoding tactics used by a band. The encoding tactics used in 510 one band are independent of those used in other bands. The space of 511 supported encoding tactics is an important part of the Pack200 512 specification. The present section introduces these encodings, 513 which are defined in detail in the section <a href="#encodings">Specification of Band Coding</a>. 514 <p>As one might expect, byte bands (which encode bytewise data such 515 as the resource file images) encode their integers as unsigned 516 8-bit bytes. This encoding is named BYTE1 in this specification. 517 (Compare the type "u1" in the class file definition.)</p> 518 <p>Other bands have values with a much larger dynamic range, 519 including (in a few cases) negative numbers, and/or values all the 520 way up to the 32-bit unsigned maximum. Most of these encodings are 521 variable-length, in the expectation that the typical band element 522 will be relatively small in magnitude, even though some elements 523 may be large and require more bytes to represent. Some bands that 524 are expected to exhibit strong correlations in their element 525 sequences are encoded as successive differences (delta encoding) 526 rather than absolute numeric values.</p> 527 <p>Each band is associated with a <em>primary encoding</em> which 528 the compressor and decompressor agree to use when transmitting 529 elements of that band. For any band after the end of the segment 530 header, except for the byte bands, the compressor can optionally 531 specify a <em>secondary encoding</em> to use instead of the primary 532 encoding. In essence, the band's encoding defaults to the primary, 533 unless there is an explicitly declared secondary. This allows the 534 Pack200 format to adapt more closely to the actual statistics of 535 band elements.</p> 536 <p>For example, most bands, such as those holding counts and sizes, 537 have a primary encoding called UNSIGNED5. This is a general-purpose 538 unsigned encoding which represents values in the range [0..191] as 539 a single byte, and scales up to a maximum size of five bytes for 540 numbers larger than about fifty million. However, if a band 541 contains only numbers in the range [0,255], the BYTE1 encoding is 542 more compact, and the compressor is allowed to instruct the 543 decompressor to use this instead.</p> 544 <p>When the compressor specifies a secondary encoding, it must emit 545 an optional <em>band coding specifier</em>, which is described in the section 546 <a href="#band_coding">Meta-Coding</a>. A customized encoding method 547 often saves many bytes, if it matches more precisely the actual 548 dynamic range of the band's element values.</p> 549 <a name="tocInEnSc" id="tocInEnSc"></a> 550 <h3>4.1. Integer Encoding Schema</h3> 551 The Pack200 format is based on a schema of integer encoding 552 systems, parameterized by four numbers (B,H,S,D). From this 553 infinite set, about 10 selected encodings serve as primary 554 encodings for bands, and about 100 more serve as optional 555 encodings. The system of (B,H,S,D) encodings is explained at length 556 in the section <a href="#encodings">Specification of Band Coding</a>. For the present 557 purposes, a brief introduction will suffice. 558 <p>The parameter B (1<=B<=5) is the maximum length in bytes 559 of the encoding of a single integer. Less significant bits are 560 always encoded in earlier bytes.</p> 561 <p>The parameter H (1<=H<=256) is the radix of the encoding. 562 it also determines the conditions under which the encoding's byte 563 sequences terminate. The co-parameter L (0<=L<=255) is 564 defined as (256-H). Encoded byte sequences are allowed to contain 565 only one byte with a value less than L, and that byte must be the 566 last in the sequence. Thus, larger H values make for longer average 567 encoding lengths. If H is 256 and L is zero, then the encoding 568 method is fixed-length, because all encodings must be exactly B 569 bytes long.</p> 570 <p>The parameter S (0<=S<=2) determines whether and how the 571 encoding represents signed numbers. (More precisely, since band 572 elements are conventionally regarded as unsigned 32-bit integers, S 573 determines the coding of band elements larger than the largest 574 31-bit unsigned number, 2147483647. But we shall continue to refer 575 to such numbers as negative, where the distinction is irrelevant.) 576 S denotes the number of least-significant bits which serve as a 577 sign bit. If S is zero, the numbers are unsigned. If S is one, the 578 LSB of the unsigned number is exclusive-ored into the right-shifted 579 remainder of the unsigned number to produce a corresponding signed 580 number. If S is more than one, the signed number produced is 581 negative only if all S least-significant bits are set, and 582 otherwise these low bits contribute to the positive magnitude of 583 the integer. This representation is efficient for bands containing 584 mostly-positive numbers, such as bytecode branch offsets. The 585 interpretation of sign bits is more precisely described in the section <a href= 586 "#tocEnSiIn">Encoding of Signed Integers</a>.</p> 587 <p>The parameter D (0<=D<=1) determines whether the band 588 transmits its data via successive differences (i.e., delta 589 encoding). In writing these encodings, the parameters S and D may 590 be omitted if both are zero, and D may be omitted if zero.</p> 591 <p>Thus, the encoding (1,256,0,0), also written as (1,256), 592 represents numbers as unsigned bytes, while (4,256) represents 593 numbers as unsigned little-endian 32-bit integers. The encoding 594 (1,256,1) maps single bytes to numbers in the range [-128,127]. The 595 encoding (1,256,1,1) expresses any sequence of numbers whose 596 successive differences are in the range [-128,127] (and whose first 597 number is in that range).</p> 598 <p>The very common encoding UNSIGNED5 can represent the full 599 unsigned range of 32-bit integers. A byte sequence in this encoding 600 consists either of four bytes less than 192 followed by an 601 arbitrary byte, or else from zero to three bytes less than 192 602 followed by a byte greater than or equal to 192. The unsigned value 603 is formed by scaling each succeeding byte by successive powers of 604 the radix 64, and adding all the scaled byte values together.</p> 605 <table border="1" summary="integer encoding scheme"> 606 <tr align="right"> 607 <th id="integer_encoding_scheme_v">value</th> 608 <th id="integer_encoding_scheme_b0">byte 0</th> 609 <th id="integer_encoding_scheme_b1">byte 1</th> 610 <th id="integer_encoding_scheme_b2">byte 2</th> 611 <th id="integer_encoding_scheme_b3">byte 3</th> 612 <th id="integer_encoding_scheme_b4">byte 4</th> 613 </tr> 614 <tr align="right"> 615 <td headers="integer_encoding_scheme_v">1</td> 616 <td headers="integer_encoding_scheme_b0">1</td> 617 <td headers="integer_encoding_scheme_b1"> </td> 618 <td headers="integer_encoding_scheme_b2"> </td> 619 <td headers="integer_encoding_scheme_b3"> </td> 620 <td headers="integer_encoding_scheme_b4"> </td> 621 </tr> 622 <tr align="right"> 623 <td headers="integer_encoding_scheme_v">191</td> 624 <td headers="integer_encoding_scheme_b0">191</td> 625 <td headers="integer_encoding_scheme_b1"> </td> 626 <td headers="integer_encoding_scheme_b2"> </td> 627 <td headers="integer_encoding_scheme_b3"> </td> 628 <td headers="integer_encoding_scheme_b4"> </td> 629 </tr> 630 <tr align="right"> 631 <td headers="integer_encoding_scheme_v">192</td> 632 <td headers="integer_encoding_scheme_b0">192</td> 633 <td headers="integer_encoding_scheme_b1">0</td> 634 <td headers="integer_encoding_scheme_b2"> </td> 635 <td headers="integer_encoding_scheme_b3"> </td> 636 <td headers="integer_encoding_scheme_b4"> </td> 637 </tr> 638 <tr align="right"> 639 <td headers="integer_encoding_scheme_v">193</td> 640 <td headers="integer_encoding_scheme_b0">193</td> 641 <td headers="integer_encoding_scheme_b1">0</td> 642 <td headers="integer_encoding_scheme_b2"> </td> 643 <td headers="integer_encoding_scheme_b3"> </td> 644 <td headers="integer_encoding_scheme_b4"> </td> 645 </tr> 646 <tr align="right"> 647 <td headers="integer_encoding_scheme_v">255</td> 648 <td headers="integer_encoding_scheme_b0">255</td> 649 <td headers="integer_encoding_scheme_b1">0</td> 650 <td headers="integer_encoding_scheme_b2"> </td> 651 <td headers="integer_encoding_scheme_b3"> </td> 652 <td headers="integer_encoding_scheme_b4"> </td> 653 </tr> 654 <tr align="right"> 655 <td headers="integer_encoding_scheme_v">256</td> 656 <td headers="integer_encoding_scheme_b0">192</td> 657 <td headers="integer_encoding_scheme_b1">1</td> 658 <td headers="integer_encoding_scheme_b2"> </td> 659 <td headers="integer_encoding_scheme_b3"> </td> 660 <td headers="integer_encoding_scheme_b4"> </td> 661 </tr> 662 <tr align="right"> 663 <td headers="integer_encoding_scheme_v">512</td> 664 <td headers="integer_encoding_scheme_b0">192</td> 665 <td headers="integer_encoding_scheme_b1">5</td> 666 <td headers="integer_encoding_scheme_b2"> </td> 667 <td headers="integer_encoding_scheme_b3"> </td> 668 <td headers="integer_encoding_scheme_b4"> </td> 669 </tr> 670 <tr align="right"> 671 <td headers="integer_encoding_scheme_v">1024</td> 672 <td headers="integer_encoding_scheme_b0">192</td> 673 <td headers="integer_encoding_scheme_b1">13</td> 674 <td headers="integer_encoding_scheme_b3"> </td> 675 <td headers="integer_encoding_scheme_v"> </td> 676 <td headers="integer_encoding_scheme_b4"> </td> 677 </tr> 678 <tr align="right"> 679 <td headers="integer_encoding_scheme_v">2048</td> 680 <td headers="integer_encoding_scheme_b0">192</td> 681 <td headers="integer_encoding_scheme_b1">29</td> 682 <td headers="integer_encoding_scheme_b2"> </td> 683 <td headers="integer_encoding_scheme_b3"> </td> 684 <td headers="integer_encoding_scheme_b4"> </td> 685 </tr> 686 <tr align="right"> 687 <td headers="integer_encoding_scheme_v">12479</td> 688 <td headers="integer_encoding_scheme_b0">255</td> 689 <td headers="integer_encoding_scheme_b1">191</td> 690 <td headers="integer_encoding_scheme_b2"> </td> 691 <td headers="integer_encoding_scheme_b3"> </td> 692 <td headers="integer_encoding_scheme_b4"> </td> 693 </tr> 694 <tr align="right"> 695 <td headers="integer_encoding_scheme_v">12480</td> 696 <td headers="integer_encoding_scheme_b0">192</td> 697 <td headers="integer_encoding_scheme_b1">192</td> 698 <td headers="integer_encoding_scheme_b2">0</td> 699 <td headers="integer_encoding_scheme_b3"> </td> 700 <td headers="integer_encoding_scheme_b4"> </td> 701 </tr> 702 <tr align="right"> 703 <td headers="integer_encoding_scheme_v">798911</td> 704 <td headers="integer_encoding_scheme_b0">255</td> 705 <td headers="integer_encoding_scheme_b1">255</td> 706 <td headers="integer_encoding_scheme_b2">191</td> 707 <td headers="integer_encoding_scheme_b3"> </td> 708 <td headers="integer_encoding_scheme_b4"> </td> 709 </tr> 710 <tr align="right"> 711 <td headers="integer_encoding_scheme_v">798912</td> 712 <td headers="integer_encoding_scheme_b0">192</td> 713 <td headers="integer_encoding_scheme_b1">192</td> 714 <td headers="integer_encoding_scheme_b2">192</td> 715 <td headers="integer_encoding_scheme_b3">0</td> 716 <td headers="integer_encoding_scheme_b4"> </td> 717 </tr> 718 <tr align="right"> 719 <td headers="integer_encoding_scheme_v">51130559</td> 720 <td headers="integer_encoding_scheme_b0">255</td> 721 <td headers="integer_encoding_scheme_b1">255</td> 722 <td headers="integer_encoding_scheme_b2">255</td> 723 <td headers="integer_encoding_scheme_b3">191</td> 724 <td headers="integer_encoding_scheme_b4"> </td> 725 </tr> 726 <tr align="right"> 727 <td headers="integer_encoding_scheme_v">51130560</td> 728 <td headers="integer_encoding_scheme_b0">192</td> 729 <td headers="integer_encoding_scheme_b1">192</td> 730 <td headers="integer_encoding_scheme_b2">192</td> 731 <td headers="integer_encoding_scheme_b3">192</td> 732 <td headers="integer_encoding_scheme_b4">0</td> 733 </tr> 734 <tr align="right"> 735 <td headers="integer_encoding_scheme_v">0xFFFFFFFF</td> 736 <td headers="integer_encoding_scheme_b0">255</td> 737 <td headers="integer_encoding_scheme_b1">252</td> 738 <td headers="integer_encoding_scheme_b2">252</td> 739 <td headers="integer_encoding_scheme_b3">252</td> 740 <td headers="integer_encoding_scheme_b4">252</td> 741 </tr> 742 </table> 743 <p>Here is the set of primary encodings used by at least one 744 band:</p> 745 <table border="1" summary="set of primary encodings"> 746 <tr> 747 <th id="set_of_primary_encodings_t">Type</th> 748 <th id="set_of_primary_encodings_n">Name</th> 749 <th id="set_of_primary_encodings_p">Purpose</th> 750 </tr> 751 <tr> 752 <td headers="set_of_primary_encodings_t">(1,256)</td> 753 <td headers="set_of_primary_encodings_n">BYTE1</td> 754 <td headers="set_of_primary_encodings_p">bytes</td> 755 </tr> 756 <tr> 757 <td headers="set_of_primary_encodings_t">(3,128)</td> 758 <td headers="set_of_primary_encodings_n">CHAR3</td> 759 <td headers="set_of_primary_encodings_p">Java characters</td> 760 </tr> 761 <tr> 762 <td headers="set_of_primary_encodings_t">(5,4)</td> 763 <td headers="set_of_primary_encodings_n">BCI5</td> 764 <td headers="set_of_primary_encodings_p">bytecode positions</td> 765 </tr> 766 <tr> 767 <td headers="set_of_primary_encodings_t">(5,4,2)</td> 768 <td headers="set_of_primary_encodings_n">BRANCH5</td> 769 <td headers="set_of_primary_encodings_p">bytecode branch 770 offsets</td> 771 </tr> 772 <tr> 773 <td headers="set_of_primary_encodings_t">(5,64)</td> 774 <td headers="set_of_primary_encodings_n">UNSIGNED5</td> 775 <td headers="set_of_primary_encodings_p">general unsigned ints</td> 776 </tr> 777 <tr> 778 <td headers="set_of_primary_encodings_t">(5,64,1)</td> 779 <td headers="set_of_primary_encodings_n">SIGNED5</td> 780 <td headers="set_of_primary_encodings_p">general signed ints</td> 781 </tr> 782 <tr> 783 <td headers="set_of_primary_encodings_t">(5,64,0,1)</td> 784 <td headers="set_of_primary_encodings_n">UDELTA5</td> 785 <td headers="set_of_primary_encodings_p">monotonic sequences</td> 786 </tr> 787 <tr> 788 <td headers="set_of_primary_encodings_t">(5,64,1,1)</td> 789 <td headers="set_of_primary_encodings_n">DELTA5</td> 790 <td headers="set_of_primary_encodings_p">autocorrelated 791 sequences</td> 792 </tr> 793 <tr> 794 <td headers="set_of_primary_encodings_t">(5,64,2,1)</td> 795 <td headers="set_of_primary_encodings_n">MDELTA5</td> 796 <td headers="set_of_primary_encodings_p">mostly monotonic 797 sequences</td> 798 </tr> 799 </table> 800 <a name="tocBanDef" id="tocBanDef"></a> 801 <h2>5. Band Definitions</h2> 802 The file as a whole consists of about 200 bands in four major 803 groups. After a header, the constant pool contents come first, 804 followed by most of the class schema, followed by a consolidation 805 of all attribute information (for classes, fields, methods, codes, 806 and the archive as a whole), and ending with bytecodes for all 807 methods. 808 <p>Rather than describe the bands in a long and dull sequence, we 809 use a simple, non-recursive grammar to present them in an organized 810 fashion. This grammar roughly parallels the grammar of a class 811 file:</p> 812 <pre class="codeblock"> 813 pack200_segment: 814 segment_header 815 *band_headers :BYTE1 816 cp_bands 817 attr_definition_bands 818 ic_bands 819 class_bands 820 bc_bands 821 file_bands 822 823 </pre> 824 <p>The terminals of this grammar are scalars and bands. To make the 825 terminals easier to recognize, scalar names begin with pound sign 826 "#" and band names begin with a star "*". A scalar is an encoded 827 integer (or a small fixed number of them) which appears within the 828 header of the archive file. When a scalar is mentioned in the 829 grammar, it is followed by a colon and the encoding and bracketed 830 count of the scalar value(s). Whenever a band is mentioned, it is 831 followed by a colon and its primary encoding, followed by a comment 832 in square brackets indicating its length. If the band encodes 833 references into some other data structure, such as a constant pool, 834 that structure is mentioned as a comment in parentheses. If the 835 references are allowed to be null, that fact is mentioned also.</p> 836 <p>Here is an example:</p> 837 <pre class="codeblock"> 838 example_non_terminal: 839 other_non_terminal 840 #single_scalar_integer :UNSIGNED5[1] 841 #four_byte_scalar :BYTE1[4] 842 *band_of_integers :UNSIGNED5 [#integer_count] 843 *band_of_method_references :UNSIGNED5 [SUM(*ref_counts)] (cp_Method) 844 *band_of_strings_and_nulls :UNSIGNED5 [...] (null or cp_String) 845 846 </pre> 847 <p>Many of the band lengths are simply references to previous 848 scalars (such as <tt>[#class_count]</tt>) or sums of previous bands 849 which transmit counts (e.g., <tt>[SUM(*class_method_count)]</tt>). 850 These bracketed lengths must be regarded as comments in the 851 grammar, since the text of the specification defines band lengths 852 verbally. Band counts which cannot be briefly summarized as 853 sometimes specified in a partial expression which contains an 854 ellipsis.</p> 855 <p>Occasionally we use additional grammatical notations. We use the 856 ordinary regular expression operators <tt>(X | Y)</tt> means a 857 match for either X or Y, <tt>(X)*</tt> means any number of matches 858 for X, <tt>(X)+</tt> means one or more matches for X, and 859 <tt>(X)?</tt> means either a match for X or nothing. In one case described in the section <a href="#band_replicated">Utf8 Constants</a>, where a band may have several 860 instances, the expression 861 <em>(band1)</em><tt> ** </tt><em>length(band2)</em> means 862 that there are as many instances of <em>band1</em> as there are 863 elements in <em>band2</em>. Likewise, in three cases, the 864 expression <em>(band1)</em><tt> ** </tt><em>#scalar</em> 865 indicates that there are zero or one instances of <em>band1</em> 866 according to the value (zero or one, respectively) of the boolean 867 scalar value.</p> 868 <a name="tocArcSeg" id="tocArcSeg"></a> 869 <h3>5.1. Archive Segmentation</h3> 870 The entire Pack200 archive format may be repeated one or more times 871 in a transmission to the decompressor. In this case, each complete 872 set of transmitted bands bands is viewed as a <em>segment</em> of 873 the whole transmission. The decompressor is required to accept 874 multiple segments, and to process each segment independently in 875 order. The output files resulting from each segment are accumulated 876 in order. If the decompressor is producing a JAR file, multiple 877 segments must be accumulated into one output JAR file, whose 878 elements are made up of the respective elements transmitted in each 879 segment, in order. 880 <pre class="codeblock"> 881 pack200_archive: 882 (pack200_segment)+ 883 884 </pre> 885 Note that each segment begins anew with the Pack200 magic number 886 and version numbers. 887 <p>(With one caveat, this means that Pack200 archives may be 888 concatenated with the natural meaning of combining the archives 889 they represent. As will be seen below, if the 890 <tt>#archive_size</tt> field is not present in each segment header, 891 it must be inserted before another segment is appended, so that the 892 decompressor can find the end of each segment. The segment header 893 format is such that this adjustment can be made easily.)</p> 894 <p>When combined with a streaming transport layer, segmentation 895 provides a way for a compressor to decrease latency or to decrease 896 the decompressor's memory requirements, at a cost in compressor 897 efficiency.</p> 898 <p>Segmentation can also help solve a scaling problem with very 899 large archives (of many tens of megabytes), in which the width of 900 indexes into the combined global constant pools can grow beyond the 901 benefits of global constant sharing. By starting a new segment, the 902 compressor resets the decompressor's constant pools, clearing out 903 useless constants, at the cost of restating constants that are 904 still in use. (The trade-offs are similar in flavor to the design 905 of copying garbage collectors.)</p> 906 <a name="tocArcHea" id="tocArcHea"></a> 907 <h3>5.2. Archive Header</h3> 908 The header consists of a magic number and version information, in a 909 format exactly parallel to the Java class file format. However, 910 besides the magic number, there are no other big-endian integers in 911 the Pack200 format. All integer encodings in bands present 912 arithmetically less-significant bits first. 913 <p>Only the archive magic numbers (the first four bytes of the 914 segment header) are fixed in size. All other archive structures are 915 variable in size and must therefore be parsed sequentially. 916 Generally speaking, decompressors must perform two passes over each 917 segment of the archive, one to size and parse the bands, and one to 918 sequentially extract information from the bands into each JAR 919 element in the output.</p> 920 <pre class="codeblock"> 921 segment_header: 922 archive_magic archive_header 923 924 archive_magic: 925 #archive_magic_word :BYTE1[4] 926 927 archive_header: 928 #archive_minver :UNSIGNED5[1] 929 #archive_majver :UNSIGNED5[1] 930 #archive_options :UNSIGNED5[1] 931 (archive_file_counts) ** (#have_file_headers) 932 (archive_special_counts) ** (#have_special_formats) 933 cp_counts 934 class_counts 935 936 archive_file_counts: 937 #archive_size_hi :UNSIGNED5[1] 938 #archive_size_lo :UNSIGNED5[1] 939 #archive_next_count :UNSIGNED5[1] 940 #archive_modtime :UNSIGNED5[1] 941 #file_count :UNSIGNED5[1] 942 943 </pre> 944 <p>The <tt>archive_magic_word</tt> consists of the four bytes 0xCA, 945 0xFE, 0xD0, 0x0D. The <tt>#archive_minver</tt> must be the number 946 1. The <tt>#archive_majver</tt> must be the number 170. Both of the 947 latter two values may be incremented in the future to reflect small 948 revisions in this file format. Note that in previous versions of 949 this standard, the minor and major version numbers were 7 and 150, 950 or 1 and 160.</p> 951 <p>The header also contains initial counts of constant pool entries 952 and other "top-level" entities. All of these counts are given in 953 UNSIGNED5 format. Some of these counts are conditionally present, 954 controlled by bits in the <tt>#archive_options</tt> word. The rule 955 for a missing header value (and for missing values in general 956 unless otherwise specified) is that the decompressor must behave as 957 if it had received an explicit zero value.</p> 958 <a name="tocArOpFiPr" id="tocArOpFiPr"></a> 959 <h4>5.2.1. Archive Options and File Properties</h4> 960 The <tt>#archive_options</tt> word is interpreted bitwise. Certain 961 bits are given symbolic names as follows, where the LSB is numbered 962 as bit zero: 963 <table border="1" summary="bits used in archive_options word"> 964 <tr> 965 <th id="archive_options_b">Bit</th> 966 <th id="archive_options_n">Name</th> 967 <th id="archive_options_m">Meaning if set in 968 <tt>#archive_options</tt></th> 969 </tr> 970 <tr> 971 <td headers="archive_options_b">0</td> 972 <td headers="archive_options_n"><tt>have_special_formats</tt></td> 973 <td headers="archive_options_m"><tt>archive_special_counts</tt> 974 contains counts</td> 975 </tr> 976 <tr> 977 <td headers="archive_options_b">1</td> 978 <td headers="archive_options_n"><tt>have_cp_numbers</tt></td> 979 <td headers="archive_options_m"><tt>cp_number_counts</tt> contains 980 counts</td> 981 </tr> 982 <tr> 983 <td headers="archive_options_b">2</td> 984 <td headers="archive_options_n"><tt>have_all_code_flags</tt></td> 985 <td headers="archive_options_m"><tt>code_flags_lo</tt> contains an 986 element for every code</td> 987 </tr> 988 <tr> 989 <td headers="archive_options_b">3</td> 990 <td headers="archive_options_n"><tt>have_cp_extra_counts</tt></td> 991 <td headers="archive_options_m"><tt>cp_extra_counts</tt> contains 992 counts</td> 993 </tr> 994 <tr> 995 <td headers="archive_options_b">4</td> 996 <td headers="archive_options_n"><tt>have_file_headers</tt></td> 997 <td headers="archive_options_m"><tt>archive_file_counts</tt> 998 contains counts</td> 999 </tr> 1000 <tr> 1001 <td headers="archive_options_b">5</td> 1002 <td headers="archive_options_n"><tt>deflate_hint</tt></td> 1003 <td headers="archive_options_m">request compressed JAR file for all 1004 elements</td> 1005 </tr> 1006 <tr> 1007 <td headers="archive_options_b">6</td> 1008 <td headers="archive_options_n"><tt>have_file_modtime</tt></td> 1009 <td headers="archive_options_m"><tt>file_modtime</tt> contains 1010 modtimes</td> 1011 </tr> 1012 <tr> 1013 <td headers="archive_options_b">7</td> 1014 <td headers="archive_options_n"><tt>have_file_options</tt></td> 1015 <td headers="archive_options_m"><tt>file_options</tt> contains 1016 option bits</td> 1017 </tr> 1018 <tr> 1019 <td headers="archive_options_b">8</td> 1020 <td headers="archive_options_n"><tt>have_file_size_hi</tt></td> 1021 <td headers="archive_options_m"><tt>file_size_hi</tt> contains 1022 high-order size words</td> 1023 </tr> 1024 <tr> 1025 <td headers="archive_options_b">9</td> 1026 <td headers="archive_options_n"><tt>have_class_flags_hi</tt></td> 1027 <td headers="archive_options_m"><tt>class_flags_hi</tt> contains 1028 extra attribute flags</td> 1029 </tr> 1030 <tr> 1031 <td headers="archive_options_b">10</td> 1032 <td headers="archive_options_n"><tt>have_field_flags_hi</tt></td> 1033 <td headers="archive_options_m"><tt>field_flags_hi</tt> contains 1034 extra attribute flags</td> 1035 </tr> 1036 <tr> 1037 <td headers="archive_options_b">11</td> 1038 <td headers="archive_options_n"><tt>have_method_flags_hi</tt></td> 1039 <td headers="archive_options_m"><tt>method_flags_hi</tt> contains 1040 extra attribute flags</td> 1041 </tr> 1042 <tr> 1043 <td headers="archive_options_b">12</td> 1044 <td headers="archive_options_n"><tt>have_code_flags_hi</tt></td> 1045 <td headers="archive_options_m"><tt>code_flags_hi</tt> contains 1046 extra attribute flags</td> 1047 </tr> 1048 <tr> 1049 <td headers="archive_options_b">13</td> 1050 <td headers="archive_options_n"> </td> 1051 <td headers="archive_options_m">(unused, must be zero)</td> 1052 </tr> 1053 <tr> 1054 <td headers="archive_options_b">...</td> 1055 <td headers="archive_options_n"> </td> 1056 <td headers="archive_options_m">(unused, must be zero)</td> 1057 </tr> 1058 <tr> 1059 <td headers="archive_options_b">31</td> 1060 <td headers="archive_options_n"> </td> 1061 <td headers="archive_options_m">(unused, must be zero)</td> 1062 </tr> 1063 </table> 1064 <p>If <tt>have_special_formats</tt> (the LSB) is set, the band 1065 <tt>archive_special_counts</tt> will have two elements, as 1066 specified in the grammar. Otherwise this band will have zero 1067 elements. Similarly, if <tt>have_cp_numbers</tt> is set, the band 1068 <tt>cp_number_counts</tt> will have four elements, as specified in 1069 the grammar. Otherwise this band will have zero elements. If 1070 <tt>have_all_code_flags</tt> is set, the band <tt>code_flags</tt> 1071 must contain one element for every <tt>Code</tt> attribute. 1072 Otherwise this band may have fewer elements. (This option is useful 1073 when <tt>Code</tt> attributes are rich in sub-attributes, perhaps 1074 because the JAR contains large amounts of debugging 1075 information.)</p> 1076 <p>If <tt>have_cp_extra_counts</tt> is set, the band 1077 <tt>cp_extra_counts</tt> will contain four elements, as specified 1078 in the grammar. Otherwise this band will have zero elements. (The 1079 flag may only be set when <tt>#archive_majver</tt> is 170 or 1080 higher. These extra counts correspond to additional constant pool 1081 types introduced in recent revisions of the classfile format.)</p> 1082 <p>If <tt>have_file_headers</tt> is set, the band 1083 <tt>archive_file_counts</tt> will have five elements, as specified 1084 in the grammar. Otherwise this band will have zero elements. If 1085 <tt>deflate_hint</tt> is set, the decompressor is requested (but 1086 not required) to reduce the size of its output. For example, if it 1087 produces a JAR file, it may deflate the JAR elements. If the option 1088 <tt>have_file_modtime</tt> (or <tt>have_file_options</tt>, 1089 <tt>have_file_size_hi</tt>, <tt>have_class_flags_hi</tt>, 1090 <tt>have_field_flags_hi</tt>, <tt>have_method_flags_hi</tt>, 1091 <tt>have_code_flags_hi</tt>, respectively) is set, the 1092 corresponding band <tt>file_modtime</tt> (or <tt>file_options</tt>, 1093 <tt>file_size_hi</tt>, <tt>class_flags_hi</tt>, 1094 <tt>field_flags_hi</tt>, <tt>method_flags_hi</tt>, 1095 <tt>code_flags_hi</tt>, respectively) may be non-empty, as 1096 specified below. Otherwise that band will have zero elements. Other 1097 bits in the archive options must be zero and are reserved for 1098 future use.</p> 1099 <p>Immediately after the <tt>#archive_options</tt> word is a pair 1100 of 32-bit numbers which together form a 64-bit length that helps 1101 decompressors easily buffer incoming data up to the end of the 1102 archive segment without reading beyond the segment. The value 1103 <tt>#archive_size</tt> is the unsigned 64-bit value composed of the 1104 unsigned 32-bit words <tt>#archive_size_lo</tt> and 1105 <tt>#archive_size_hi</tt>, where the former value is the low-order 1106 32-bit word and the latter value is the high-order 32-bit word. The 1107 value <tt>#archive_size</tt> is either zero or declares the number 1108 of bytes in the archive segment, starting immediately after 1109 <tt>#archive_size_lo</tt> and before <tt>#archive_next_count</tt> 1110 and ending with the last band, the <tt>*file_bits</tt> band. (That 1111 is, a non-zero size includes the size of 1112 <tt>#archive_next_count</tt>, <tt>*file_bits</tt>, and everything 1113 in between.) This value is redundant, but if non-zero must be 1114 correctly supplied by any compressor. If the archive segment is 1115 transmitted as part of a stream, and if other data (such as 1116 additional segments) follow the archive, the <tt>#archive_size</tt> 1117 value must not be zero. Although it may be completely ignored by 1118 the decompressor, this value may help some decompressors to buffer 1119 their inputs more efficiently.</p> 1120 <p>Immediately after <tt>#archive_size</tt> is another value 1121 <tt>#archive_next_count</tt> which estimates the number of archive 1122 segments immediately following the current one. This number need 1123 not be correct, and may always be zero. It is intended to provide 1124 decompressors with a hint as to the amount of remaining 1125 decompression work to do. (Such hints are routinely displayed in 1126 progress bars.)</p> 1127 <p>If the <tt>#archive_modtime</tt> value is non-zero, the 1128 decompressor is requested (but not required) to adjust the 1129 system-specific modification time for its output. For example, if 1130 the decompressor produces a JAR file, it may set the modification 1131 date of each JAR element, or of the JAR file itself, to that date, 1132 in the absence of any more specific directive, such a non-zero 1133 <tt>file_modtime</tt> value. The <tt>#archive_modtime</tt> value is 1134 interpreted as the number of seconds since the epoch used by 1135 <tt>System.currentTimeMillis</tt>, which is 1/1/1970, 00:00:00 GMT. 1136 However, the special value zero is reserved to indicate the absence 1137 of any modification time for the archive as a whole. A decompressor 1138 may supply an arbitrary value in place of a missing archive 1139 modification time. If this is done, and if <tt>file_modtime</tt> 1140 values are present, those values are interpreted relative to 1141 modification time supplied for <tt>#archive_modtime</tt> by the 1142 compressor.</p> 1143 <p>The <tt>#file_count</tt> value gives the number of files which 1144 are described in detail by the archive. Note that a class file 1145 which is simple enough (as described below) does not need to be 1146 described as a file, because it is enough that the class itself is 1147 transmitted. Therefore, <tt>#file_count</tt> may be less than the 1148 number of transmitted classes. (This latter number is called 1149 <tt>#class_count</tt>.) On the other hand, transmitted files do not 1150 need to contain classes, so that <tt>#file_count</tt> can also be 1151 greater than the number of classes.</p> 1152 <a name="tocArEnCoClFo" id="tocArEnCoClFo"></a> 1153 <h4>5.2.2. Archive Entity Counts and Class Format</h4> 1154 The archive file contains up to sixteen sets of constants called 1155 "constant pools". (These structures are analogous, but not 1156 identical, to a similarly named structure in class files.) These 1157 constant pools are described in detail in the next section. 1158 <p>The cardinality of each constant pool is given in UNSIGNED5 1159 format in elements of the <tt>cp_counts</tt> structure of the 1160 archive header:</p> 1161 <pre class="codeblock"> 1162 cp_counts: 1163 #cp_Utf8_count :UNSIGNED5[1] 1164 (cp_number_counts) ** (#have_cp_numbers) 1165 #cp_String_count :UNSIGNED5[1] 1166 #cp_Class_count :UNSIGNED5[1] 1167 #cp_Signature_count :UNSIGNED5[1] 1168 #cp_Descr_count :UNSIGNED5[1] 1169 #cp_Field_count :UNSIGNED5[1] 1170 #cp_Method_count :UNSIGNED5[1] 1171 #cp_Imethod_count :UNSIGNED5[1] 1172 (cp_extra_counts) ** (#have_cp_extra_counts) 1173 1174 cp_number_counts: 1175 #cp_Int_count :UNSIGNED5[1] 1176 #cp_Float_count :UNSIGNED5[1] 1177 #cp_Long_count :UNSIGNED5[1] 1178 #cp_Double_count :UNSIGNED5[1] 1179 1180 cp_extra_counts: 1181 #cp_MethodHandle_count :UNSIGNED5[1] 1182 #cp_MethodType_count :UNSIGNED5[1] 1183 #cp_BootstrapMethod_count :UNSIGNED5[1] 1184 #cp_InvokeDynamic_count :UNSIGNED5[1] 1185 1186 archive_special_counts: 1187 #band_headers_size :UNSIGNED5[1] 1188 #attr_definition_count :UNSIGNED5[1] 1189 1190 class_counts: 1191 #ic_count :UNSIGNED5[1] 1192 #default_class_minver :UNSIGNED5[1] 1193 #default_class_majver :UNSIGNED5[1] 1194 #class_count :UNSIGNED5[1] 1195 1196 </pre> 1197 The order in which these counts occur parallels the order in which 1198 the constant pools themselves are transmitted in the archive. This 1199 order is called the <em>definition order</em> of the constant 1200 pools. 1201 <p>The four numeric constant pools are sized by 1202 <tt>cp_number_counts</tt>. They specify numbers used occasionally 1203 by <tt>ldc</tt> bytecodes. Because a minority of classes actually 1204 use such bytecodes, the sizes are optional, under the control of 1205 <tt>#have_cp_numbers</tt>.</p> 1206 <p>Likewise, the last four constant pools are sized by 1207 <tt>cp_extra_counts</tt>. They specify linkage information for the 1208 <tt>invokedynamic</tt> instruction, and certain types of constants 1209 (method handles and method types). As with the numeric entries, 1210 these sizes are optional, under the control of 1211 <tt>#have_cp_extra_counts</tt>.</p> 1212 <p>Every class file has a header that includes magic number and a 1213 minor and major version numbers. The magic number (0xCAFEBABE), 1214 being a fixed constant, is not transmitted in the Pack200 archive. 1215 However, the version numbers, which can vary somewhat, must be 1216 recorded.</p> 1217 <p>In the expectation that particular version numbers will be 1218 prevalent, the archive header transmits default major and minor 1219 version numbers. Both of these numbers are given in UNSIGNED5 1220 format.</p> 1221 <p>Individual classes in the archive (as described in the section <a href= 1222 "#special_version_number">Attribute Bands</a>) may optionally specify their 1223 own version numbers in a pseudo-attribute which overrides the 1224 <tt>#default_class_minver</tt> and <tt>#default_class_majver</tt> 1225 given in the archive header.</p> 1226 <p>The count <tt>#band_headers_size</tt> gives the size in bytes of 1227 <tt>band_headers</tt>. The format of these bytes, which help define 1228 band coding specifiers for secondary codings, will be discussed 1229 much later, in the section <a href="#band_coding">Meta-Coding</a>.</p> 1230 <p>The archive header also specifies the number of attribute types 1231 (<tt>#attr_definition_count</tt>), class definitions 1232 (<tt>#class_count</tt>), nested class declarations 1233 (<tt>#ic_count</tt>). These numbers are used to size various other 1234 bands, as noted in the definition of those bands.</p> 1235 <p>The arithmetic sum of all numbers in <tt>cp_counts</tt> must be 1236 less than the value <tt>536870912</tt> (<tt>2^29</tt>). A 1237 compressor is forbidden to transmit an archive for which the sum 1238 reaches or exceeds this limit. This constraint is intended to allow 1239 decompressors to use, internally, a unified numbering of constants, 1240 even if certain constants (such as demangled inner class names or 1241 implicit <tt>SourceFile</tt> names) must be added on the fly during 1242 decompression to the constant pool.</p> 1243 <p>Note on implementation: The <tt>archive_header</tt> directly 1244 contains 3 numbers, while <tt>cp_counts</tt> contains at least 8 1245 numbers and <tt>class_counts</tt> contains exactly 4. Therefore, 1246 the minimum size of the <tt>archive_header</tt> is 15 bytes, and 1247 this is always preceded by 4 bytes of <tt>archive_magic</tt>. A 1248 decompressor which wished to avoid any spurious read-ahead could 1249 read and buffer an initial block of 19 bytes, which would be 1250 certain to contain the <tt>#archive_size</tt> fields. (This assumes 1251 that the version numbers are small, as they are.) It could then 1252 immediately parse enough information to determine how many 1253 additional bytes of buffer storage would be required to scan the 1254 rest of the archive, at least up to the resource file images. By 1255 the time the resource file images in <tt>*file_bits</tt> must be 1256 parsed, the decompressor will have already read the 1257 <tt>*file_size</tt> bands, and will be able to remove any 1258 uncertainty originally present in <tt>#archive_size</tt>. (If the 1259 <tt>#archive_size</tt> fields are zero, the decompressor may be 1260 forced to read blindly up to the end of all data on the input 1261 channel in order to parse the archive.)</p> 1262 <a name="tocConPoo" id="tocConPoo"></a> 1263 <h4>5.3. Constant Pools</h4> 1264 The format defines sixteen independent constant pools, eleven of 1265 which correspond directly to the eleven basic types of constants 1266 found in Java class files. In the Pack200 archive format, they are 1267 organized in a fixed logical ordering called their <em>definition 1268 order</em>. This order determines their presentation in the 1269 archive's band structure, and also the construction of certain 1270 constant numberings. 1271 <p>The constant pools consolidate the information in the constant 1272 pools of all input class files. Each constant pool contains a 1273 single type of constant value. Each of the eleven constant pool 1274 types found in Java 6 class files is placed in its own constant 1275 pool. A twelfth pool holds <em>signatures</em>, which in class 1276 files are UTF8 strings that represent method and field types, but 1277 in Pack200 archives are a separately compressed data type.</p> 1278 <p>Three more constant pools hold constants defined as part of the 1279 Java 7 classfile format (major version 51 or later). One more 1280 constant pool holds constants to be assembled into the 1281 <tt>BootstrapMethods</tt> attribute, which may be viewed as an 1282 appendix to the classfile constant pool.</p> 1283 <p>The following table gives the sixteen predefined constant pools 1284 in their definition order. It also defines their correspondence 1285 with the constant types found in the Java class file format.</p> 1286 <table border="1" summary="Constant pools in definition order"> 1287 <tr> 1288 <th id="definition_order_n">Name</th> 1289 <th id="definition_order_e">class file element</th> 1290 <th id="definition_order_t">class file tag</th> 1291 <th id="definition_order_p">Purpose</th> 1292 </tr> 1293 <tr> 1294 <td headers="definition_order_n">cp_Utf8</td> 1295 <td headers="definition_order_e">CONSTANT_Utf8_info</td> 1296 <td headers="definition_order_t">CONSTANT_Utf8</td> 1297 <td headers="definition_order_p">basic string data</td> 1298 </tr> 1299 <tr> 1300 <td headers="definition_order_n">cp_Int</td> 1301 <td headers="definition_order_e">CONSTANT_Integer_info</td> 1302 <td headers="definition_order_t">CONSTANT_Integer</td> 1303 <td headers="definition_order_p">int constant</td> 1304 </tr> 1305 <tr> 1306 <td headers="definition_order_n">cp_Float</td> 1307 <td headers="definition_order_e">CONSTANT_Float_info</td> 1308 <td headers="definition_order_t">CONSTANT_Float</td> 1309 <td headers="definition_order_p">float constant</td> 1310 </tr> 1311 <tr> 1312 <td headers="definition_order_n">cp_Long</td> 1313 <td headers="definition_order_e">CONSTANT_Long_info</td> 1314 <td headers="definition_order_t">CONSTANT_Long</td> 1315 <td headers="definition_order_p">long constant</td> 1316 </tr> 1317 <tr> 1318 <td headers="definition_order_n">cp_Double</td> 1319 <td headers="definition_order_e">CONSTANT_Double_info</td> 1320 <td headers="definition_order_t">CONSTANT_Double</td> 1321 <td headers="definition_order_p">double constant</td> 1322 </tr> 1323 <tr> 1324 <td headers="definition_order_n">cp_String</td> 1325 <td headers="definition_order_e">CONSTANT_String_info</td> 1326 <td headers="definition_order_t">CONSTANT_String</td> 1327 <td headers="definition_order_p">String constant</td> 1328 </tr> 1329 <tr> 1330 <td headers="definition_order_n">cp_Class</td> 1331 <td headers="definition_order_e">CONSTANT_Class_info</td> 1332 <td headers="definition_order_t">CONSTANT_Class</td> 1333 <td headers="definition_order_p">class reference</td> 1334 </tr> 1335 <tr> 1336 <td headers="definition_order_n">cp_Signature</td> 1337 <td headers="definition_order_e">(see below)</td> 1338 <td headers="definition_order_t">(none)</td> 1339 <td headers="definition_order_p">method, field, or variable 1340 type</td> 1341 </tr> 1342 <tr> 1343 <td headers="definition_order_n">cp_Descr</td> 1344 <td headers="definition_order_e">CONSTANT_NameAndType_info</td> 1345 <td headers="definition_order_t">CONSTANT_NameAndType</td> 1346 <td headers="definition_order_p">pair of (name, type)</td> 1347 </tr> 1348 <tr> 1349 <td headers="definition_order_n">cp_Field</td> 1350 <td headers="definition_order_e">CONSTANT_Fieldref_info</td> 1351 <td headers="definition_order_t">CONSTANT_Fieldref</td> 1352 <td headers="definition_order_p">field reference</td> 1353 </tr> 1354 <tr> 1355 <td headers="definition_order_n">cp_Method</td> 1356 <td headers="definition_order_e">CONSTANT_Methodref_info</td> 1357 <td headers="definition_order_t">CONSTANT_Methodref</td> 1358 <td headers="definition_order_p">method call</td> 1359 </tr> 1360 <tr> 1361 <td headers="definition_order_n">cp_Imethod</td> 1362 <td headers="definition_order_e"> 1363 CONSTANT_InterfaceMethodref_info</td> 1364 <td headers="definition_order_t">CONSTANT_InterfaceMethodref</td> 1365 <td headers="definition_order_p">interface call</td> 1366 </tr> 1367 <tr> 1368 <td headers="definition_order_n">cp_MethodHandle</td> 1369 <td headers="definition_order_e">CONSTANT_MethodHandle_info</td> 1370 <td headers="definition_order_t">CONSTANT_MethodHandle</td> 1371 <td headers="definition_order_p">method handle constant</td> 1372 </tr> 1373 <tr> 1374 <td headers="definition_order_n">cp_MethodType</td> 1375 <td headers="definition_order_e">CONSTANT_MethodType_info</td> 1376 <td headers="definition_order_t">CONSTANT_MethodType</td> 1377 <td headers="definition_order_p">method type constant</td> 1378 </tr> 1379 <tr> 1380 <td headers="definition_order_n">cp_BootstrapMethod</td> 1381 <td headers="definition_order_e"> 1382 BootstrapMethods_attribute.bootstrap_methods[i]</td> 1383 <td headers="definition_order_t">(none; side table to constant 1384 pool)</td> 1385 <td headers="definition_order_p">bootstrap method specifier</td> 1386 </tr> 1387 <tr> 1388 <td headers="definition_order_n">cp_InvokeDynamic</td> 1389 <td headers="definition_order_e">CONSTANT_InvokeDynamic_info</td> 1390 <td headers="definition_order_t">CONSTANT_InvokeDynamic</td> 1391 <td headers="definition_order_p">invokedynamic call</td> 1392 </tr> 1393 </table> 1394 <p>(Note that the definition order for these constant pools 1395 is similar to the numeric ordering of the corresponding class file 1396 tag. For example, CONSTANT_Utf8 is the first tag, and cp_Utf8 1397 is the first constant pool in the definition order. 1398 However, there are differences in detail. In particular, 1399 note that cp_String comes before cp_Class, even though 1400 the corresponding class file tags are in the reverse order.)</p> 1401 1402 <p>Each constant pool is logically a set of symbolic or numeric 1403 values, all of one type. In the Pack200 archive, it is structured 1404 as a sequence of such values, each with a unique index within the 1405 sequence. Elsewhere in the archive, whenever a constant must be 1406 mentioned, its index within the appropriate constant pool (or 1407 within a subset of a pool, or within a group of pools) is 1408 given.</p> 1409 <p>Unlike the class file format, constant pool indexing in the 1410 Pack200 archive format starts at zero. In the rare places where 1411 null references are expected, the possibility is documented, and 1412 the null references themselves are encoded by a zero index, while 1413 all other index values are incremented by one. Where null 1414 references are not expected, they may still be encoded by the 1415 32-bit index value -1.</p> 1416 <p>Also unlike class files, there are no "gaps" or unused indexes 1417 associated with long or double values. Occasionally, we will refer 1418 formally to an element of a constant pool by using array notation. 1419 For example, the first three integers in the <tt>cp_Int</tt> 1420 constant pool are <tt>cp_Int[0]</tt>, <tt>cp_Int[1]</tt>, and 1421 <tt>cp_Int[2]</tt>, and the last integer is 1422 <tt>cp_Int[cp_Int_count-1]</tt>. Note that both bands and constant 1423 pools are treated in this specification as arrays with zero 1424 origin.</p> 1425 <p>It is illegal for a compressor to transmit the same constant 1426 twice. That is, all constant pool entries must be unique.</p> 1427 <p>In a class file, with a few exceptions, constant pool references 1428 are strongly typed, in that every reference either is null or 1429 refers to a constant pool entry of a fixed tag associated with the 1430 context of the reference. The exceptions are <tt>ConstantValue</tt> 1431 attributes and operand fields of the <tt>ldc</tt>, <tt>ldc_w</tt>, 1432 and <tt>ldc2_w</tt> instructions.</p> 1433 <p>However, because constant pools in a Pack200 archive are 1434 separately indexed, all constant references must be strongly typed, 1435 so that there is only one constant pool (or subset of a pool) into 1436 which any given index applies. This is accomplished either by 1437 deducing the constant type from context (in the case of 1438 <tt>ConstantValue</tt> attributes) or adding extra information to 1439 the context of the reference. (Within the bytecode stream, 1440 <tt>ldc</tt> is split out by constant type into distinct 1441 instructions <tt>sldc</tt>, <tt>ildc</tt>, etc.)</p> 1442 <p>The layout of constant pool bands in the archive follows the 1443 definition order of the constant pools themselves. Each constant 1444 pool is represented in its turn by a sequence of one or more bands. 1445 The sequence of constant pool bands is therefore structured as 1446 follows:</p> 1447 <pre class="codeblock"> 1448 cp_bands: 1449 cp_Utf8 1450 *cp_Int :UDELTA5 [#cp_Int_count] 1451 *cp_Float :UDELTA5 [#cp_Float_count] 1452 cp_Long 1453 cp_Double 1454 *cp_String :UDELTA5 [#cp_String_count] (cp_Utf8) 1455 *cp_Class :UDELTA5 [#cp_Class_count] (cp_Utf8) 1456 cp_Signature 1457 cp_Descr 1458 cp_Field 1459 cp_Method 1460 cp_Imethod 1461 cp_MethodHandle 1462 *cp_MethodType :UDELTA5 [#cp_MethodType_count] (cp_Signature) 1463 cp_BootstrapMethod 1464 cp_InvokeDynamic 1465 1466 </pre> 1467 <p>As can be seen here, constant pools whose entries can be derived 1468 from a single 32-bit integer or a single reference are represented 1469 as single bands. The other constant pools are represented as groups 1470 of bands. Each constant pool gives its name to a corresponding 1471 grammar element. The production of <tt>cp_bands</tt> declares the 1472 order of each band or group of bands that transmits the constants 1473 in the eponymous constant pool.</p> 1474 <p>Note the use of UDELTA5 as primary encodings for several bands. 1475 Although the Pack200 file format does not require any particular 1476 ordering of values in constant pools, it is generally advantageous 1477 to order them so that the encoded values in bands using UDELTA5 are 1478 monotonically increasing. (Negative deltas can be encoded, although 1479 expensively, by UDELTA5. Also, a signed secondary encoding may be 1480 chosen by the compressor instead of UDELTA5.) The choice of primary 1481 encodings in this specification reflects an expectation that 1482 high-quality compressors, when presented with a choice of output 1483 orderings, will make choices that result in good use of primary 1484 band encodings.</p> 1485 <p>In a few cases, several of the sixteen constant pools are 1486 combined into a group, so that indexes can be formed to refer to 1487 elements of the group as a whole. Such a group is completely 1488 defined by its constituent constant pools. An index into a constant 1489 pool group is always formed consistently with the overall order of 1490 the constituent constant pools, as well as with the internal order 1491 of each pool. For example, if a group <tt>cp_ABC</tt> is formed of 1492 three pools <tt>cp_A</tt>, <tt>cp_B</tt>, and <tt>cp_C</tt> of 1493 sizes <tt>COUNT(cp_A)</tt>, <tt>COUNT(cp_B)</tt>, and 1494 <tt>COUNT(cp_C)</tt>, respectively, then a group index selects from 1495 one of the three pools depending on whether it is in the range 1496 <tt>0 .. COUNT(cp_A)-1</tt>, <tt>COUNT(cp_A) .. 1497 COUNT(cp_A)+COUNT(cp_B)-1</tt>, or <tt>COUNT(cp_A)+COUNT(cp_B) .. 1498 COUNT(cp_ABC)-1</tt>, respectively. The size of the pool group is 1499 of course the sum of the constituent pools.</p> 1500 <p>In some other cases, subsets of constant pools are indexed in an 1501 abbreviated fashion. An index into a constant pool subset is always 1502 formed consistently with the order of the pool itself. For example, 1503 the index <tt>0</tt> always refers to the first element of the 1504 subset, the index <tt>1</tt> refers to the second, and so on.</p> 1505 <p>Here are definitions of the pool groups used in this 1506 specification.</p> 1507 <table border="1" summary="Constant pool groups"> 1508 <tr> 1509 <th id="cp_groups_n">Name</th> 1510 <th id="cp_groups_c">Constituents</th> 1511 <th id="cp_groups_p">Purpose</th> 1512 </tr> 1513 <tr> 1514 <td headers="cp_groups_n">cp_All</td> 1515 <td headers="cp_groups_c">(all sixteen pools)</td> 1516 <td headers="cp_groups_p">generic references</td> 1517 </tr> 1518 <tr> 1519 <td headers="cp_groups_n">cp_LoadableValue</td> 1520 <td headers="cp_groups_c">cp_Int, cp_Float, cp_Long, cp_Double, cp_String, 1521 cp_Class, cp_MethodHandle, cp_MethodType</td> 1522 <td headers="cp_groups_p"><tt>qldc</tt> operand, bootstrap method 1523 argument</td> 1524 </tr> 1525 <tr> 1526 <td headers="cp_groups_n">cp_AnyMember</td> 1527 <td headers="cp_groups_c">cp_Field, cp_Method, cp_Imethod</td> 1528 <td headers="cp_groups_p"><tt>get</tt> or <tt>invoke</tt> operand, 1529 method handle component</td> 1530 </tr> 1531 </table> 1532 The group <tt>cp_All</tt> comprises the sequence of all constants, 1533 in their natural order of occurrence within the Pack200 archive. 1534 Thus, an index into <tt>cp_All</tt> is in effect an untyped 1535 reference to any constant. <a name="tocScaCon" id="tocScaCon"></a> 1536 <h5>5.3.1. Scalar Constants</h5> 1537 The encoding of the <tt>cp_Utf8</tt> constant pool will be 1538 described shortly. First we will describe the coding of the 1539 numeric, string, and class constant pools. 1540 <p>The values in the <tt>cp_Int</tt> constant pool are directly 1541 represented by the values encoded in its band. The values in the 1542 <tt>cp_Float</tt> constant pool are obtained as if by applying 1543 <tt>java.lang.Float.intBitsToFloat</tt> to the 32-bit values 1544 encoded in its band.</p> 1545 <p>The 64-bit values of the <tt>cp_Long</tt> band are obtained by 1546 adjoining, as high and low words, corresponding 32-bit values from 1547 the two bands <tt>cp_Long_hi</tt> and <tt>cp_Long_lo</tt>. (They 1548 contain the high and low words, respectively.) Likewise, the values 1549 of the <tt>cp_Double</tt> band are obtained by first adjoining high 1550 and low words from two other bands, and then retyping the resulting 1551 64-bit integers as if by applying 1552 <tt>java.lang.Double.longBitsToDouble</tt>. The high and low words 1553 are in the bands <tt>cp_Double_hi</tt> and <tt>cp_Double_lo</tt>, 1554 respectively.</p> 1555 <pre class="codeblock"> 1556 cp_Long: 1557 *cp_Long_hi :UDELTA5 [#cp_Long_count] 1558 *cp_Long_lo :DELTA5 [#cp_Long_count] 1559 1560 cp_Double: 1561 *cp_Double_hi :UDELTA5 [#cp_Double_count] 1562 *cp_Double_lo :DELTA5 [#cp_Double_count] 1563 1564 </pre> 1565 <p>When floating point values are eventually written to class 1566 files, their bits must be accurately stored, as if they were 1567 processed by <tt>java.lang.Float.floatToRawIntBits</tt> or 1568 <tt>java.lang.Double.doubleToRawLongBits</tt>. In this way "NaN" 1569 values are transmitted faithfully, without normalization.</p> 1570 <p>(Note: Although it would be possible to extend the band-coding 1571 techniques of Pack200 to encode 64-bit values directly, this file 1572 format always transmits 64-bit values as pairs of 32-bit values, 1573 transmitted in pairs of bands. This simplifies implementations, 1574 allowing them to process band data with 32-bit data paths.)</p> 1575 <p>Each string in a <tt>cp_String</tt> constant pool is represented 1576 in its band by a reference to the string's spelling, as a 1577 <tt>cp_Utf8</tt> constant.</p> 1578 <p>Likewise, each class in a <tt>cp_Class</tt> constant pool is 1579 represented in its band by a reference to the class's spelling, as 1580 a <tt>cp_Utf8</tt> constant. (As in the class file and the VM, the 1581 spelling uses the slash character to delimit package prefix 1582 components.)</p> 1583 <a name="str_psc_ref" id="str_psc_ref"></a> <a name="tocUtfCon" id= 1584 "tocUtfCon"></a> 1585 <h5>5.3.2. Utf8 Constants</h5> 1586 Each value in the <tt>cp_Utf8</tt> constant pool is an array of 1587 zero or more 16-bit Java characters. (The name "Utf8" is an 1588 anachronism, referring only to the basic character string type in 1589 Java class files. No part of the Pack200 file format uses any UTF 1590 encoding, but the term "Utf8" is retained to emphasize the 1591 connection with class files.) As in the class file format, all 1592 character string data is transmitted in this one kind of constant 1593 pool entry. When the context is clear enough, we loosely refer to 1594 these arrays as "strings", even though they are distinct from the 1595 Java constants in the cp_String constant pool. 1596 <p>If <tt>cp_Utf8</tt> is not empty, its first value is always the 1597 empty string. Thus, the empty string is always given an index of 1598 zero. No band values are transmitted to represent this empty 1599 string. (Values in the bands <tt>cp_Utf8_prefix</tt> and 1600 <tt>cp_Utf8_suffix</tt> pertain to strings after the empty string 1601 in <tt>cp_Utf8</tt>.) Because constants cannot be duplicated, all 1602 other elements of <tt>cp_Utf8</tt> contain at least one 1603 character.</p> 1604 <p>Each string in the <tt>cp_Utf8</tt> constant pool is represented 1605 in the archive file in two parts, a prefix and a suffix. The suffix 1606 is represented both by a count and a sequence of character codes. 1607 The prefix is represented only by a count; the characters of the 1608 prefix are duplicated from the previous string. This technique 1609 allows the compressor (if it chooses) to represent strings by means 1610 of their successive differences. The first suffix value and the 1611 first two prefix values are suppressed in the transmitted archive. 1612 The values, if transmitted, would always be zero, since the first 1613 <tt>cp_Utf8</tt> string is always empty, and the second string can 1614 never share a non-empty prefix with the first string.</p> 1615 <p>Each suffix is transmitted in exactly one of two ways, as a 1616 <em>small suffix</em> or a <em>big suffix</em>. Small suffixes are 1617 transmitted contiguously in one large band. Big suffixes are rare; 1618 they are intended as a way to compactly transmit strings with 1619 unusual statistics, such as strings which are really tables of 1620 numeric data. Each big suffix is transmitted in its own band. This 1621 allows the compressor the option to choose an efficiently 1622 customized secondary coding for the characters in each large, 1623 unusual string.</p> 1624 <a name="band_replicated" id="band_replicated"></a> 1625 <pre class="codeblock"> 1626 cp_Utf8: 1627 *cp_Utf8_prefix :DELTA5 [MAX(0,#cp_Utf8_count-2)] 1628 *cp_Utf8_suffix :UNSIGNED5 [MAX(0,#cp_Utf8_count-1)] 1629 *cp_Utf8_chars :CHAR3 [SUM( *cp_Utf8_suffix )] 1630 *cp_Utf8_big_suffix :DELTA5 [COUNT(0, *cp_Utf8_suffix )] 1631 (*cp_Utf8_big_chars :DELTA5) 1632 ** length(cp_Utf8_big_suffix) [SUM( *cp_Utf8_big_suffix )] 1633 1634 </pre> 1635 (Note: It is helpful, but not required by this specification, to 1636 order the strings lexicographically and find maximal common 1637 prefixes between adjacent strings. It is permissible to ignore the 1638 prefix sharing feature and declare all prefixes to be zero.) 1639 <p>The band <tt>cp_Utf8_suffix</tt> contains one less than 1640 <tt>#cp_Utf8_count</tt> elements. It specifies, in order, the small 1641 suffix length of each constant pool string (except the implicit 1642 first string, which is empty). The band <tt>cp_Utf8_prefix</tt> 1643 contains two less than <tt>#cp_Utf8_count</tt> elements. It 1644 specifies, in order, the prefix length of each constant pool string 1645 (except the first two strings, which always have zero prefix 1646 lengths). The prefix length encodes the length of a prefix 1647 substring shared by both <tt>cp_Utf8[i-1]</tt> and 1648 <tt>cp_Utf8[i]</tt>. If there are fewer than three strings in 1649 <tt>cp_Utf8</tt>, then <tt>cp_Utf8_prefix</tt> is empty. The prefix 1650 length is typically a large proportion (sometimes half) of the 1651 total length.</p> 1652 <p>Each value in the band <tt>cp_Utf8_chars</tt> is a 16-bit number 1653 expressing a Java character. This band contains the characters of 1654 all small suffixes, in order. For each successive string, 1655 <tt>cp_Utf8_chars</tt> contains an additional run of values 1656 encoding the characters of its small suffix, if any. Therefore, the 1657 total length of this band is the sum of all values in the 1658 <tt>cp_Utf8_suffix</tt> band.</p> 1659 1660 <a name="big_string" id="big_string"></a> 1661 1662 <p>Whenever a small suffix length for a constant pool entry is 1663 zero, the string has no small suffix, but a big suffix instead. The 1664 length of each big suffix is given by an element of the 1665 <tt>cp_Utf8_big_suffix</tt> band. (Therefore, the length of this 1666 band is precisely the count of zero values in the 1667 <tt>cp_Utf8_suffix</tt> band.) Each big suffix is transmitted as a 1668 separate band of 16-bit character values, one band element per 1669 character. There is one such band per big suffix. These bands 1670 immediately follow the <tt>cp_Utf8_big_suffix</tt> band, and are 1671 collectively called the <tt>cp_Utf8_big_chars</tt> bands. Although 1672 normally data of the same type are collected into a single band, 1673 these strings are placed in separate bands so that they may be 1674 independently encoded. These strings typically encode arrays of 1675 binary data, rather than true Java characters.</p> 1676 1677 <p>A big suffix can have a length of zero, which means that the 1678 constant pool entry is a non-empty prefix of the previous string. 1679 In such a case, the corresponding suffix band will occupy no space 1680 in the archive file, since bands of zero length occupy no bytes at 1681 all.</p> 1682 1683 <p>Please see the Appendix section <a href= 1684 "#str_psc">Representation of <code>cp_Utf8</code> Constant Pool</a> for pseudo-code explaining this concept. <a name= 1685 "sig_psc_ref" id="sig_psc_ref"></a></p> 1686 <a name="tocTypSig" id="tocTypSig"></a> 1687 <h5>5.3.3. Type Signatures</h5> 1688 Each <tt>cp_Signature</tt> constant pool entry represents a type 1689 string, exactly as field and method types are declared in the class 1690 file format. Although the class file format uses simple 1691 <tt>Utf8</tt> constant pool entries for such strings, the Pack200 1692 file format allocates a separate constant pool for them, in order 1693 to use more compact representation than for general strings. 1694 <p>Signature constants are special in that they can contain 1695 embedded references to <tt>cp_Class</tt> constants. The signature 1696 constant is equivalent to a Utf8 constant, once the embedded class 1697 references are expanded into their spellings. Signature constants 1698 are flexible enough to represent arbitrary strings, but are 1699 intended for strings that often contain class names following the 1700 capital letter ell <tt>'L'</tt>. These include field, method, and 1701 local variables types, and generic <tt>Signature</tt> 1702 attributes.</p> 1703 <p>Each signature string is decomposed into a <em>form</em> and a 1704 sequence of zero or more class references. The class references are 1705 obtained by locating in the original signature string all sequences 1706 that match the pattern "<tt>L</tt><em>classname</em>", removing the 1707 <em>classname</em> part, and treating it as a reference into the 1708 <tt>cp_Class</tt> constant pool. The form is defined as the residue 1709 after the class names have been removed from the original 1710 string.</p> 1711 <p>The form is not allowed to contain any occurrences of the letter 1712 ell ('<tt>L</tt>'), other than those which mark removed class 1713 names.</p> 1714 <p>Thus, the form will contain the character '<tt>L</tt>' wherever 1715 the original type string refers to a class. By counting the number 1716 of these characters in a form, the decompressor may deduce the 1717 number of classes to which the original type string refers. This 1718 number is called the <em>class length</em> of the form.</p> 1719 <p>Note that <tt>cp_Class</tt> constants are not required to refer 1720 to existing classes, nor are they even required to have valid class 1721 name spellings. Therefore, the compressor has considerable latitude 1722 in choosing which class names (if any) it will extract from 1723 signature strings. In an extreme case, the compressor can make each 1724 form identical to its corresponding signature string, and simply 1725 satisfy its class length by emitting references to a fictitious 1726 class with an empty name. (This class length would have to include 1727 any occurrences of <tt>'L'</tt> in the class names themselves.)</p> 1728 <p>Note also that these encoding rules do not require a class name 1729 to be followed by any particular character, although it will 1730 generally be a semicolon, or perhaps a left-angle bracket, in the 1731 case of an instance of a generic type in a <tt>Signature</tt> 1732 attribute.</p> 1733 <p>The rules also allow the compressor to decide, arbitrarily, how 1734 many characters (if any) after each letter ell <tt>'L'</tt> will be 1735 transmitted as part of a class name. Therefore, a given signature 1736 string may be representable by several forms, any of which the 1737 decompressor must be prepared to process.</p> 1738 <p>Here are some examples:</p> 1739 <table border="1" summary="sample decompressions"> 1740 <tr align="center"> 1741 <th id="sample_decompressions_t">Type Signature String</th> 1742 <th id="sample_decompressions_f">Form</th> 1743 <th id="sample_decompressions_c">Class<br /> 1744 Len.</th> 1745 <th id="sample_decompressions_c2">Class...</th> 1746 </tr> 1747 <tr> 1748 <td headers="sample_decompressions_t"><tt>F</tt></td> 1749 <td headers="sample_decompressions_f"><tt>F</tt></td> 1750 <td headers="sample_decompressions_c">0</td> 1751 <td headers="sample_decompressions_c2"> </td> 1752 </tr> 1753 <tr> 1754 <td headers="sample_decompressions_t"><tt>[Z</tt></td> 1755 <td headers="sample_decompressions_f"><tt>[Z</tt></td> 1756 <td headers="sample_decompressions_c">0</td> 1757 <td headers="sample_decompressions_c2"> </td> 1758 </tr> 1759 <tr> 1760 <td headers="sample_decompressions_t"><tt>[[[LLL;</tt></td> 1761 <td headers="sample_decompressions_f"><tt>[[[L;</tt></td> 1762 <td headers="sample_decompressions_c">1</td> 1763 <td headers="sample_decompressions_c2"><tt>LL</tt></td> 1764 </tr> 1765 <tr> 1766 <td headers="sample_decompressions_t"><tt>[[[LLL;</tt></td> 1767 <td headers="sample_decompressions_f"><tt>[[[LLL;</tt></td> 1768 <td headers="sample_decompressions_c">3</td> 1769 <td headers="sample_decompressions_c2"><tt>(empty), (empty), 1770 (empty)</tt></td> 1771 </tr> 1772 <tr> 1773 <td headers="sample_decompressions_t"> 1774 <tt>([Ljava/lang/String;)V</tt></td> 1775 <td headers="sample_decompressions_f"><tt>([L;)V</tt></td> 1776 <td headers="sample_decompressions_c">1</td> 1777 <td headers="sample_decompressions_c2"> 1778 <tt>java/lang/String</tt></td> 1779 </tr> 1780 <tr> 1781 <td headers="sample_decompressions_t"> 1782 <tt>Ljava/util/List<Lpkg/Item;>;</tt></td> 1783 <td headers="sample_decompressions_f"><tt>L<L;>;</tt></td> 1784 <td headers="sample_decompressions_c">2</td> 1785 <td headers="sample_decompressions_c2"><tt>java/util/List, 1786 pkg/Item</tt></td> 1787 </tr> 1788 <tr> 1789 <td headers="sample_decompressions_t"> 1790 <tt>(Ljava/lang/String;II)Lpkg/Item;</tt></td> 1791 <td headers="sample_decompressions_f"><tt>(L;II)L;</tt></td> 1792 <td headers="sample_decompressions_c">2</td> 1793 <td headers="sample_decompressions_c2"><tt>java/lang/String, 1794 pkg/Item</tt></td> 1795 </tr> 1796 <tr> 1797 <td headers="sample_decompressions_t"> 1798 <tt>Ljava/util/List<Ljava/lang/Byte;>;</tt></td> 1799 <td headers="sample_decompressions_f"><tt>L<L;>;</tt></td> 1800 <td headers="sample_decompressions_c">2</td> 1801 <td headers="sample_decompressions_c2"><tt>java/util/List, 1802 java/lang/Byte</tt></td> 1803 </tr> 1804 <tr> 1805 <td headers="sample_decompressions_t"> 1806 <tt><ELEM:>(Ljava/util/List<TELEM;>;)TELEM;</tt></td> 1807 <td headers="sample_decompressions_f"> 1808 <tt><EL:>(L<TEL;>;)TEL;</tt></td> 1809 <td headers="sample_decompressions_c">1</td> 1810 <td headers="sample_decompressions_c2"><tt>EM, java/util/List, EM, 1811 EM</tt></td> 1812 </tr> 1813 <tr> 1814 <td headers="sample_decompressions_t"><tt>ALLOWABLE</tt></td> 1815 <td headers="sample_decompressions_f"><tt>ALLOWABLE</tt></td> 1816 <td headers="sample_decompressions_c">3</td> 1817 <td headers="sample_decompressions_c2"><tt>(empty), (empty), 1818 (empty)</tt></td> 1819 </tr> 1820 <tr> 1821 <td headers="sample_decompressions_t"><tt>ALLOWABLE</tt></td> 1822 <td headers="sample_decompressions_f"><tt>AL</tt></td> 1823 <td headers="sample_decompressions_c">1</td> 1824 <td headers="sample_decompressions_c2"><tt>LOWABLE</tt></td> 1825 </tr> 1826 <tr> 1827 <td headers="sample_decompressions_t"><tt>ALLOWABLE</tt></td> 1828 <td headers="sample_decompressions_f"><tt>ALABL</tt></td> 1829 <td headers="sample_decompressions_c">2</td> 1830 <td headers="sample_decompressions_c2"><tt>LOW, E</tt></td> 1831 </tr> 1832 </table> 1833 <p>The forms of all strings in the <tt>cp_Signature</tt> constant 1834 pool are given in order in the <tt>cp_Signature_form</tt> band, as 1835 one <tt>cp_Utf8</tt> reference per signature string. For each form, 1836 the class-length sequence of classes required to reconstitute the 1837 signature string is transmitted as a run of <tt>cp_Class</tt> 1838 references in the <tt>cp_Signature_classes</tt> band. As a 1839 consequence of these definitions, the length of the 1840 <tt>cp_Signature_classes</tt> band is the total number of letter 1841 ell <tt>'L'</tt> occurrences in the sequence of spellings of forms 1842 mentioned in <tt>cp_Signature_form</tt>.</p> 1843 <pre class="codeblock"> 1844 cp_Signature: 1845 *cp_Signature_form :DELTA5 [#cp_Signature_count](cp_Utf8) 1846 *cp_Signature_classes :UDELTA5 [COUNT('L',...)] (cp_Class) 1847 1848 </pre> 1849 <p>Please see the Appendix section for <a href= 1850 "#sig_psc">Representation of <code>cp_Signature</code> Constant Pool</a> pseudo-code explaining this concept.</p> 1851 <a name="tocTupCon" id="tocTupCon"></a> 1852 <h5>5.3.4. Tuple Constants</h5> 1853 The next four constant pools contain ordered pairs of various kinds 1854 of values (types, names, strings, or classes). Each 1855 <tt>cp_Descr</tt> constant is an ordered pair of a name 1856 (represented as a <tt>cp_Utf8</tt> reference) and a type 1857 (represented as a <tt>cp_Signature</tt> reference). These 1858 references are transmitted in corresponding elements of the 1859 <tt>cp_Descr_name</tt> and <tt>cp_Descr_type</tt> bands. 1860 <p>Likewise, each <tt>cp_Field</tt>, <tt>cp_Method</tt>, or 1861 <tt>cp_Imethod</tt> constant is an ordered pair of a class 1862 (represented as a <tt>cp_Class</tt> reference) and a name-and-type 1863 descriptor (represented as a <tt>cp_Descr</tt> reference). Again, 1864 these references are transmitted in corresponding elements of the 1865 associated bands.</p> 1866 <pre class="codeblock"> 1867 cp_Descr: 1868 *cp_Descr_name :DELTA5 [#cp_Descr_count] (cp_Utf8) 1869 *cp_Descr_type :UDELTA5 [#cp_Descr_count] (cp_Signature) 1870 cp_Field: 1871 *cp_Field_class :DELTA5 [#cp_Field_count] (cp_Class) 1872 *cp_Field_desc :UDELTA5 [#cp_Field_count] (cp_Descr) 1873 cp_Method: 1874 *cp_Method_class :DELTA5 [#cp_Method_count] (cp_Class) 1875 *cp_Method_desc :UDELTA5 [#cp_Method_count] (cp_Descr) 1876 cp_Imethod: 1877 *cp_Imethod_class :DELTA5 [#cp_Imethod_count] (cp_Class) 1878 *cp_Imethod_desc :UDELTA5 [#cp_Imethod_count] (cp_Descr) 1879 1880 </pre> 1881 <a name="tocExtCon" id="tocExtCon"></a> 1882 <h5>5.3.5. Extra Constants</h5> 1883 For additional constant pools define symbolic references for 1884 <tt>invokedynamic</tt> instructions and related entities. (These 1885 constant pools are only non-empty if their corresponding counts are 1886 non-zero, which in turn can only be true if 1887 <tt>cp_extra_counts</tt> is present.) Each <tt>cp_MethodHandle</tt> 1888 is an ordered pair of a reference kind (a small integer) and a 1889 reference to an element of <tt>cp_Field</tt>, <tt>cp_Method</tt>, 1890 or <tt>cp_Imethod</tt>. (This reference is transmitted as an index 1891 into <tt>cp_AnyMember</tt>, which is defined above as a pool group 1892 containing those three pools.) Each <tt>cp_MethodType</tt> is 1893 represented as a <tt>cp_Signature</tt> reference. Each 1894 <tt>cp_InvokeDynamic</tt> is an ordered pair of a bootstrap method 1895 specifier (represented as a <tt>cp_BootstrapMethod</tt>) and a type 1896 (represented as a <tt>cp_Signature</tt> reference). Each 1897 <tt>cp_BootstrapMethod</tt> specifier is an ordered pair of a 1898 bootstrap method reference (represented as a 1899 <tt>cp_MethodHandle</tt>) and a counted series of zero or more 1900 constant pool references to constants which can be loaded onto the 1901 JVM stack. (These references are transmitted as indexes into the 1902 pool group <tt>cp_LoadableValue</tt>.) All these values and 1903 references are transmitted in associated bands as described below. 1904 <pre class="codeblock"> 1905 cp_MethodHandle: 1906 *cp_MethodHandle_refkind :DELTA5 [#cp_MethodHandle_count] 1907 *cp_MethodHandle_member :UDELTA5 [#cp_MethodHandle_count] (cp_AnyMember) 1908 cp_BootstrapMethod: 1909 *cp_BootstrapMethod_ref :DELTA5 [#cp_BootstrapMethod_count] (cp_MethodHandle) 1910 *cp_BootstrapMethod_arg_count :UDELTA5 [#cp_BootstrapMethod_count] 1911 *cp_BootstrapMethod_arg :DELTA5 [SUM(*BootstrapMethod_arg_count)] (cp_LoadableValue) 1912 cp_InvokeDynamic: 1913 *cp_InvokeDynamic_spec :DELTA5 [#cp_InvokeDynamic_count] (cp_BootstrapMethod) 1914 *cp_InvokeDynamic_descr :UDELTA5 [#cp_InvokeDynamic_count] (cp_Descr) 1915 </pre> 1916 <a name="tocFilAtt" id="tocFilAtt"></a> 1917 <h4>5.4. File Attributes</h4> 1918 Since a JAR archive consists of a sequence of files, each with 1919 contents and a few other attributes, the Pack200 archive can also 1920 represent a sequence of files with their attributes. Of course, the 1921 contents of class files are specially transmitted, but whether a 1922 file (i.e., a JAR archive element) contains a class or another 1923 resource, the Pack200 archive is able to transmit the following 1924 attributes: 1925 <ul> 1926 <li>name of file <em>(optional for classes)</em></li> 1927 <li>contents of file <em>(optional for classes)</em></li> 1928 <li>modification time of file <em>(optional)</em></li> 1929 <li>deflation hint for file <em>(optional)</em></li> 1930 <li>order of file in archive <em>(optional for classes)</em></li> 1931 </ul> 1932 <p>A class file whose contents are compressed by Pack200 is marked 1933 as a "stub" with a special option bit. A class stub file must be 1934 declared to have a length of zero. It may be declared to have the 1935 empty string for its name. If there are not enough class stub files 1936 transmitted to match with the number of classes transmitted, the 1937 decompressor must act as if the compressor had transmitted an 1938 additional series of trivial stubs, with no name or contents, and 1939 modification time and deflation hint copied from the archive 1940 header.</p> 1941 <p>Each resource file is transmitted in the Pack200 archive as a 1942 simple bytewise image, under a relative pathname using slash '/' as 1943 a directory separator. (This is the same pathname convention as is 1944 used in ZIP archives.) Each file (both resource files and class 1945 files) can optionally be associated with a deflation hint and a 1946 modification date.</p> 1947 <pre class="codeblock"> 1948 file_bands: 1949 *file_name :UNSIGNED5 [#file_count] (cp_Utf8) 1950 *file_size_hi :UNSIGNED5 [#file_count*(#have_file_size_hi)] 1951 *file_size_lo :UNSIGNED5 [#file_count] 1952 *file_modtime :DELTA5 [#file_count*(#have_file_modtime)] 1953 *file_options :UNSIGNED5 [#file_count*(#have_file_options)] 1954 *file_bits :BYTE1 [SUM(*file_size)] 1955 1956 </pre> 1957 <p>There are no additional file attributes, such as comments, extra 1958 attributes, or CRC values. An application which requires such 1959 attributes on some files may encode those files into an appropriate 1960 archive file format (such as ZIP), and transmit those archives as 1961 resource files in a Pack200 archive.</p> 1962 <p>Each file name is transmitted as an element of the 1963 <tt>file_name</tt> band, and each length (in bytes) is transmitted 1964 in the corresponding elements of the <tt>file_size_lo</tt> band and 1965 (if present) the <tt>file_size_hi</tt> band. All three bands are of 1966 length <tt>#file_count</tt>, except that <tt>file_size_hi</tt> has 1967 zero elements if the <tt>have_file_size_hi</tt> bit in the 1968 <tt>#archive_options</tt> is clear.</p> 1969 <p>The length in bytes of each file is the corresponding unsigned 1970 32-bit value taken from the <tt>file_size_lo</tt> band, if the 1971 <tt>file_size_hi</tt> band is empty. Otherwise, the file length is 1972 the unsigned 64-bit value composed of the corresonding unsigned 1973 32-bit elements of the <tt>file_size_lo</tt> and 1974 <tt>file_size_hi</tt> bands, where the former value is the 1975 low-order 32-bit word and the latter value is the high-order 32-bit 1976 word.</p> 1977 <p>The bytes of all non-class (i.e., resource) files follow 1978 immediately in the <tt>file_bits</tt> band. Each file is given as a 1979 corresponding run of byte values.</p> 1980 <p>The optional band <tt>file_modtime</tt>, if not empty, supplies 1981 a modification time for each resource file (and potentially for 1982 class files, if class file stubs are present). Each integer value 1983 gives a difference (in seconds) from the <tt>#archive_modtime</tt> 1984 value. (Therefore, if the <tt>#archive_modtime</tt> value is zero, 1985 the individual file times must be interpreted as absolute values.) 1986 The order of transmission of <tt>file_modtime</tt> is consistent 1987 with <tt>file_name</tt>. This band is empty if the 1988 <tt>have_file_modtime</tt> bit in the <tt>#archive_options</tt> is 1989 clear.</p> 1990 <p>The optional band <tt>file_options</tt>, if not empty, supplies 1991 flag bits for each resource file (and potentially for class files, 1992 if class file stubs are present). This band is empty if the 1993 <tt>have_file_options</tt> bit in the <tt>#archive_options</tt> is 1994 clear. Each <tt>file_options</tt> word is interpreted bitwise. 1995 Certain bits are given symbolic names as follows, where the LSB is 1996 numbered as bit zero:</p> 1997 <table border="1" summary="description of file_options bits"> 1998 <tr> 1999 <th id="file_options_b">Bit</th> 2000 <th id="file_options_n">Name</th> 2001 <th id="file_options_p">Purpose</th> 2002 </tr> 2003 <tr> 2004 <td headers="file_options_b">0</td> 2005 <td headers="file_options_n">deflate_hint</td> 2006 <td headers="file_options_p">request compressed JAR file 2007 element</td> 2008 </tr> 2009 <tr> 2010 <td headers="file_options_b">1</td> 2011 <td headers="file_options_n">is_class_stub</td> 2012 <td headers="file_options_p">this file contains class 2013 bytecodes</td> 2014 </tr> 2015 </table> 2016 <p>If <tt>deflate_hint</tt> (the LSB) is set, the decompressor is 2017 requested (but not required) to reduce the size of its output. For 2018 example, if it produces a JAR file, it may deflate the JAR 2019 elements. Since the <tt>deflate_hint</tt> bit in the 2020 <tt>#archive_options</tt> word has the same effect, the two bits 2021 are in effect combined with a logical OR for each file. If 2022 <tt>is_class_stub</tt> (the second LSB) is set, this resource file 2023 description is actually a <em>stub</em>, and the file contents are 2024 defined as the bytecodes of one of the classes defined in the 2025 Pack200 archive. Other bits in the file options must be zero and 2026 are reserved for future use.</p> 2027 <p>If a transmitted file is marked as a class stub, its contents 2028 must be transmitted as if the file were empty. (That is, 2029 <tt>file_size_hi</tt> and <tt>file_size_lo</tt> must both be zero, 2030 and there may not be any corresponding bytes in 2031 <tt>file_bits</tt>.) The decompressor is required to supply 2032 contents for the resource file by reconstituting the contents of a 2033 class file for a class transmitted in <tt>class_this</tt>, etc. 2034 Like any other resource file, the class stub is allowed to have a 2035 name, a modification time and a <tt>deflate_hint</tt>.</p> 2036 <p>The class stubs and classes correspond in order. Define the 2037 derived parameter <tt>#class_stub_count</tt> as the number of files 2038 marked as class stubs. (It is also the count of 2039 <tt>is_class_stub</tt> bits set in <tt>file_options</tt>.) Then 2040 <tt>#class_stub_count</tt> must be no larger than 2041 <tt>#class_count</tt>. The first class stub defines a file which 2042 receives bytecodes for the first class, and so on. Although a class 2043 stub has a name (transmitted in <tt>file_name</tt>), this name may 2044 be the empty string. In this case, the decompressor is required to 2045 use the standard name for the class file, which is created from the 2046 class's bytecode name (using slash '/' for a package separator) by 2047 appending the string ".class". (Thus, a classfile can have an 2048 arbitrary non-standard name, but the compression works best if its 2049 name is derived from its class in the usual way.)</p> 2050 <p>If <tt>#class_count</tt> is larger than 2051 <tt>#class_stub_count</tt>, then the decompressor must behave as if 2052 a sufficient number of trivial extra class stubs were transmitted 2053 after the last explicit file. These trivial stubs have an empty 2054 name string and a zero <tt>deflate_hint</tt> or 2055 <tt>file_modtime</tt>.</p> 2056 <p>Thus, in the simple case where there are no class stubs at all 2057 (perhaps because <tt>have_file_options</tt> is zero), the 2058 decompressor must produce its files in their transmission order, 2059 followed by the transmission order of the classes. Each class file 2060 must have its standard name, and a modification time and deflation 2061 hint inherited from <tt>#archive_modtime</tt> and the 2062 <tt>deflate_hint</tt> bit in <tt>#archive_options</tt>. But at the 2063 cost of extra transmission size, the compressor can direct the 2064 decompressor to present the resources and class files in any fixed 2065 order, with arbitrary names, modification times, and deflation 2066 hints for each output file. The decompressor must honor this 2067 ordering, if its output is in a form (such as a JAR archive) where 2068 order is significant.</p> 2069 <p>Compressors are free, unless otherwise directed, to choose any 2070 ordering of files. It is often advantageous to place files with 2071 similar statistics next to each other, so that the post-pass 2072 compressor (if any) may process their contents together (in the 2073 same window, in the case of the DEFLATE algorithm). It is likely 2074 that a compressor which is able to reorder its input files for 2075 efficient transmission will have a command option which forces it 2076 to retain the order in which input files were presented, because 2077 this order is significant to some (but not all) deployment 2078 applications.</p> 2079 <p>Compressors are free to transmit class files as if they were 2080 resource files. This provides a way to transmit class files which 2081 must be preserved bit-for-bit, or which compressors cannot transmit 2082 compressed with sufficient accuracy. Decompressors are required to 2083 accept class files transmitted "bitwise" as resource files.</p> 2084 <p>Note: The bands controlling files and their attributes are 2085 transmitted last in the archive, in order to ease decompressor 2086 implementation slightly, since the last thing a decompressor does 2087 is to assemble output files. In particular, resource files can be 2088 of arbitrary size, and placing their bits at the end of the archive 2089 allows the decompressor to avoid allocating temporary storage for 2090 them.</p> 2091 <a name="tocFlaAtt" id="tocFlaAtt"></a> 2092 <h4>5.5. Flags and Attributes</h4> 2093 The Pack200 file format directly supports up to 16 modifier bits in 2094 all output flags fields, as defined by the class file format. It 2095 also directly supports certain predefined attributes, such as 2096 <tt>Code</tt>, <tt>InnerClasses</tt>, and <tt>ConstantValue</tt> It 2097 is also possible for the compressor to define additional 2098 attributes, passing enough information to the decompressor to 2099 properly extract their data from bands and reconstitute them in 2100 class files. The presence or absence of all attributes is 2101 controlled by the setting of certain bits in flag bands. 2102 <p>Five sets of <em>flag bands</em> carry modifier bits and/or 2103 attribute control bits. The <tt>ic_flags</tt> band carries modifier 2104 bits for nested classes. Also, modifier and attribute control bits 2105 are carried by <tt>class_flags_lo</tt>, <tt>field_flags_lo</tt>, 2106 <tt>method_flags_lo</tt>, and <tt>code_flags_lo</tt>, and the four 2107 corresponding optional high word bands, <tt>class_flags_hi</tt>, 2108 <tt>field_flags_hi</tt>, <tt>method_flags_hi</tt>, and 2109 <tt>code_flags_hi</tt>. (There is no high word for 2110 <tt>ic_flags</tt>.) Each value in these bands is interpreted as an 2111 unsigned 32-bit binary number. Each bit in these bands 2112 independently specifies the presence of a Java access modifier 2113 (such as <tt>ACC_PRIVATE</tt>), or of a class, field, method, or 2114 code attribute (such as <tt>Deprecated</tt> or 2115 <tt>SourceFile</tt>), or of some other necessary control 2116 information (such as whether a class file has a non-default version 2117 number).</p> 2118 <p>Every class (resp. field, method, <tt>Code</tt> attribute) has a 2119 corresponding flags value of up to 63 bits transmitted in 2120 <tt>class_flags_lo</tt> (resp., <tt>field_flags_lo</tt>, 2121 <tt>method_flags_lo</tt>, <tt>code_flags_lo</tt>) and optionally in 2122 <tt>class_flags_hi</tt> (resp., <tt>field_flags_hi</tt>, 2123 <tt>method_flags_hi</tt>, <tt>code_flags_hi</tt>). These flags 2124 values, assembled into 64-bit numbers, are named 2125 <tt>class_flags</tt> (resp., <tt>field_flags</tt>, 2126 <tt>method_flags</tt>, <tt>code_flags</tt>). Except for 2127 <tt>Code</tt> attributes, each of the low sixteen flag bits may be 2128 used to transmit access flags. The high sixteen bits (or 2129 forty-seven, if the optional high word is transmitted) are used to 2130 indicate the presence of attributes, either predefined or 2131 compressor-defined. The sixty-fourth bit position of a flags value 2132 (if transmitted) is reserved and must be zero.</p> 2133 <p>The flags value for a <tt>Code</tt> attribute is optional and 2134 taken to be zero if missing. A <tt>Code</tt> attribute has a 2135 corresponding flags value transmitted if and only if either the 2136 <tt>have_all_code_flags</tt> bit in the <tt>#archive_options</tt> 2137 is set, or else the element of <tt>code_headers</tt> corresponding 2138 to the <tt>Code</tt> attribute has the special value zero. (See the 2139 discussion of code headers in the section <a href="#code_headers">Class Schema</a>.)</p> 2140 <p>For classes, nested classes, fields, and methods, the assignment 2141 of flag bit positions to modifiers is the same as that in the class 2142 file format. (For example, the LSB always represents 2143 <tt>ACC_PUBLIC</tt>, in both Pack200 archive and class file 2144 formats.) An <em>overflow attribute</em> is an attribute whose 2145 presence is not indicated directly via a flag bit, and but is 2146 instead indicated by a occurrence of its index in a separate band. 2147 For classes, fields, methods, and codes, bit 16 (as set in the mask 2148 0x0001000) indicates the presence of overflow attributes. For 2149 nested classes, flag bit 16 indicates the presence of explicit 2150 outer class and name fields, as explained in the section <a href= 2151 "#explicit_outer">Nested Classes</a>.</p> 2152 <table border="1" summary="Listing of flag bits"> 2153 <tr align="center"> 2154 <th id="flag_bits_b">Bit</th> 2155 <th id="flag_bits_m">Meaning</th> 2156 </tr> 2157 <tr> 2158 <td headers="flag_bits_b" align="right">0</td> 2159 <td headers="flag_bits_m">ACC_PUBLIC</td> 2160 </tr> 2161 <tr> 2162 <td headers="flag_bits_b" align="right">1</td> 2163 <td headers="flag_bits_m">ACC_PRIVATE</td> 2164 </tr> 2165 <tr> 2166 <td headers="flag_bits_b" align="right">2</td> 2167 <td headers="flag_bits_m">ACC_PROTECTED</td> 2168 </tr> 2169 <tr> 2170 <td headers="flag_bits_b" align="right">3</td> 2171 <td headers="flag_bits_m">ACC_STATIC</td> 2172 </tr> 2173 <tr> 2174 <td headers="flag_bits_b" align="right">4</td> 2175 <td headers="flag_bits_m">ACC_FINAL</td> 2176 </tr> 2177 <tr> 2178 <td headers="flag_bits_b" align="right">5</td> 2179 <td headers="flag_bits_m">ACC_SYNCHRONIZED (ACC_SUPER)</td> 2180 </tr> 2181 <tr> 2182 <td headers="flag_bits_b" align="right">6</td> 2183 <td headers="flag_bits_m">ACC_VOLATILE (ACC_BRIDGE*)</td> 2184 </tr> 2185 <tr> 2186 <td headers="flag_bits_b" align="right">7</td> 2187 <td headers="flag_bits_m">ACC_TRANSIENT (ACC_VARARGS*)</td> 2188 </tr> 2189 <tr> 2190 <td headers="flag_bits_b" align="right">8</td> 2191 <td headers="flag_bits_m">ACC_NATIVE</td> 2192 </tr> 2193 <tr> 2194 <td headers="flag_bits_b" align="right">9</td> 2195 <td headers="flag_bits_m">ACC_INTERFACE</td> 2196 </tr> 2197 <tr> 2198 <td headers="flag_bits_b" align="right">10</td> 2199 <td headers="flag_bits_m">ACC_ABSTRACT</td> 2200 </tr> 2201 <tr> 2202 <td headers="flag_bits_b" align="right">11</td> 2203 <td headers="flag_bits_m">ACC_STRICT</td> 2204 </tr> 2205 <tr> 2206 <td headers="flag_bits_b" align="right">12</td> 2207 <td headers="flag_bits_m">ACC_SYNTHETIC</td> 2208 </tr> 2209 <tr> 2210 <td headers="flag_bits_b" align="right">13</td> 2211 <td headers="flag_bits_m">ACC_ANNOTATION</td> 2212 </tr> 2213 <tr> 2214 <td headers="flag_bits_b" align="right">14</td> 2215 <td headers="flag_bits_m">ACC_ENUM</td> 2216 </tr> 2217 <tr> 2218 <td headers="flag_bits_b" align="right">16</td> 2219 <td headers="flag_bits_m">overflow (more band data elsewhere)</td> 2220 </tr> 2221 </table> 2222 <a name="tocAsFlBiAt" id="tocAsFlBiAt"></a> 2223 <h5>5.5.1. Assignment of Flag Bits to Attributes</h5> 2224 The assignment of flag bit positions to attributes is done at the 2225 option of the compressor, and is independently specified by the 2226 compressor for the four kinds of flag words that have to do with 2227 attribute-carrying objects (in classes, fields, methods, and 2228 codes). When a flag bit position is assigned to an attribute, if 2229 that bit is visible in the class file, it must be forced clear 2230 before the decompressor writes it to the class file. Therefore, if 2231 the compressor expects the decompressor to reproduce a particular 2232 non-zero flag bit as output, the compressor must refrain from 2233 assigning that bit position to attributes. 2234 <p>In particular, the low-order 16 bits of class, field, and method 2235 flags are visible in the class file, and can thus carry modifier 2236 bits. None of the bits of a code flags word is visible in the class 2237 file; these flag bits are used only for code sub-attributes.</p> 2238 <p>By contrast, the low-order 16 bits of nested class records are 2239 used solely for modifiers, since nested class records do not 2240 contain attributes. In the rest of this section on attributes, we 2241 will disregard the flag words associated with nested class 2242 records.</p> 2243 <p>Any of the 63 bit positions in a flags value can be assigned by 2244 the compressor to indicate to the decompressor the presence of some 2245 particular attribute. The compressor may "take over" a modifier bit 2246 by assigning it an attribute definition. (This is done by emitting 2247 a definition for the attribute, which mentions that bit 2248 position.)</p> 2249 <p>If the compressor "takes over" a bit (modifier or not) that is 2250 being used by default for another purpose, the bit loses its 2251 previous meaning. However, the compressor may not emit an explicit 2252 definition for the same bit twice (in the same context).</p> 2253 <p>Each kind of attribute is defined by four pieces of information: 2254 the entity to which it applies (class, field, method, or code), the 2255 bit position, if any, to which it is assigned, the name of the 2256 attribute (as it appears in the class file), and the layout of the 2257 attribute (which allows the decompressor to properly format 2258 occurrences of the attribute in the class file). It is an error for 2259 the compressor to specify the same name and layout twice in the 2260 same context. It is not an error to repeat a name with a different 2261 layout, or a layout with a different name.</p> 2262 <p>The first two items are bit-encoded into a single-byte "header", 2263 and transmitted in the <tt>attr_definition_headers</tt> band. The 2264 last two items are transmitted as <tt>cp_Utf8</tt> references in 2265 corresponding elements of the <tt>attr_definition_name</tt> and 2266 <tt>attr_definition_layout</tt>. Thus there are three bands by 2267 which the compressor declares attribute types to the decompressor, 2268 and each band is of length <tt>#attr_definition_count</tt>.</p> 2269 <pre class="codeblock"> 2270 attr_definition_bands: 2271 *attr_definition_headers :BYTE1 [#attr_definition_count] 2272 *attr_definition_name :UNSIGNED5 [#attr_definition_count] (cp_Utf8) 2273 *attr_definition_layout :UNSIGNED5 [#attr_definition_count] (cp_Utf8) 2274 2275 </pre> 2276 <p>The least significant two bits of an attribute definition header 2277 byte are treated as an unsigned field, and give the attribute's 2278 <em>context type</em>, which is type of entity to which the 2279 attribute applies:</p> 2280 <table border="1" summary= 2281 "description of least two significant bits of an attribute definition header byte"> 2282 <tr align="center"> 2283 <th id="l2sb_h"><tt>(h & 0x03)</tt></th> 2284 <th id="l2sb_c">Context Type</th> 2285 </tr> 2286 <tr> 2287 <td headers="l2sb_h" align="right">0</td> 2288 <td headers="l2sb_c">attribute applies to classes</td> 2289 </tr> 2290 <tr> 2291 <td headers="l2sb_h" align="right">1</td> 2292 <td headers="l2sb_c">attribute applies to fields</td> 2293 </tr> 2294 <tr> 2295 <td headers="l2sb_h" align="right">2</td> 2296 <td headers="l2sb_c">attribute applies to methods</td> 2297 </tr> 2298 <tr> 2299 <td headers="l2sb_h" align="right">3</td> 2300 <td headers="l2sb_c">attribute applies to Code attributes</td> 2301 </tr> 2302 </table> 2303 <p>The most significant six bits of an attribute definition header 2304 byte are treated as an unsigned field, and give the optional bit 2305 position to which the attribute is assigned in the flags word.</p> 2306 <table border="1" summary= 2307 "definition of two most significant bits of an attribute definition header byte"> 2308 <tr align="center"> 2309 <th id="m2sb_h" align="right"><tt>(h >> 2)</tt></th> 2310 <th id="m2sb_f">Flag Bit Assignment</th> 2311 </tr> 2312 <tr> 2313 <td headers="m2sb_h" align="right">0</td> 2314 <td headers="m2sb_f">overflow attribute, not assigned to any 2315 bit</td> 2316 </tr> 2317 <tr> 2318 <td headers="m2sb_h" align="right">1</td> 2319 <td headers="m2sb_f">attribute assigned to bit 0 (LSB of lo 2320 word)</td> 2321 </tr> 2322 <tr> 2323 <td headers="m2sb_h" align="right">2</td> 2324 <td headers="m2sb_f">attribute assigned to bit 1</td> 2325 </tr> 2326 <tr> 2327 <td headers="m2sb_h" align="right">3</td> 2328 <td headers="m2sb_f">attribute assigned to bit 2</td> 2329 </tr> 2330 <tr> 2331 <td headers="m2sb_h" align="center">...</td> 2332 <td headers="m2sb_f"></td> 2333 </tr> 2334 <tr> 2335 <td headers="m2sb_h" align="right">32</td> 2336 <td headers="m2sb_f">attribute assigned to bit 31 (MSB of lo 2337 word)</td> 2338 </tr> 2339 <tr> 2340 <td headers="m2sb_h" align="right">33</td> 2341 <td headers="m2sb_f">attribute assigned to bit 32 (LSB of hi 2342 word)</td> 2343 </tr> 2344 <tr> 2345 <td headers="m2sb_h" align="center">...</td> 2346 <td headers="m2sb_f"></td> 2347 </tr> 2348 <tr> 2349 <td headers="m2sb_h" align="right">63</td> 2350 <td headers="m2sb_f">attribute assigned to bit 62</td> 2351 </tr> 2352 <tr> 2353 <td headers="m2sb_h" align="right">(no value)</td> 2354 <td headers="m2sb_f">bit 63 must be zero (MSB of hi word)</td> 2355 </tr> 2356 </table> 2357 <p>Every class attribute, whether predefined in this specification 2358 or explicitly defined by the compressor, has a unique number called 2359 its <em>attribute index</em>. If the attribute is assigned a flag 2360 bit, then its attribute index is identical to the flag bit's 2361 position (a number in [0..62]). (All predefined attributes are 2362 assigned a flag bit by default.)</p> 2363 <p>If a class attribute is not assigned a flag bit, it is an 2364 overflow attribute, and its index is assigned sequentially in the 2365 order in which class attributes are defined (i.e., transmitted). 2366 The first index to be assigned sequentially in this way is 32 if 2367 <tt>#have_class_flags_hi</tt> is clear, and 63 if it is set. These 2368 indexes are used within the archive to declare attribute 2369 occurrences for individual classes.</p> 2370 <p>Likewise, field, method, and code attributes are assigned their 2371 own attribute indexes, independently of class attributes and of 2372 each other. Therefore, an attribute (i.e., a name and layout pair) 2373 is uniquely specified within the archive by its context type and 2374 attribute index. The field and method attributes may be assigned to 2375 flag bits, or else they are overflow attributes with indexes of 32 2376 or larger. Like other attributes, code attributes may be assigned 2377 explicit numbers or implicitly assigned indexes starting with 32. 2378 (As with class attributes, if the high flag word bands are selected 2379 by the appropriate bit of <tt>#archive_options</tt>, then field, 2380 method, or code overflow attributes have indexes of 63 or 2381 larger.)</p> 2382 <p>Some attributes are predefined, and do not require the 2383 compressor to emit definitions for them. They have implicitly 2384 defined layouts and flag bit assignments (i.e., indexes).</p> 2385 <p>Attribute indexes less than 63 are usable in all cases, but they 2386 may conflict with those assigned to predefined attributes, 2387 including predefined attributes defined (in the range 16 to 62) in 2388 future expansions of the Pack200 format. In the present version, 2389 all predefined attributes have indexes in the range [17..31], so 2390 that modifier flags are not taken over by default, and high flag 2391 words do not need to be used routinely.</p> 2392 <p>Here are the names and index assignments of the predefined 2393 attributes. (The predefined layouts are given below.)</p> 2394 <table border="1" summary= 2395 "Names and index assignments of predefined attributes"> 2396 <tr align="center"> 2397 <th id="predef_i">Index</th> 2398 <th id="predef_c">Context Type</th> 2399 <th id="predef_n">Name</th> 2400 </tr> 2401 <tr> 2402 <td headers="predef_i" align="right">16</td> 2403 <td headers="predef_c">C,F,M</td> 2404 <td headers="predef_n">(overflow attributes)</td> 2405 </tr> 2406 <tr> 2407 <td headers="predef_i" align="right">17</td> 2408 <td headers="predef_c">Class</td> 2409 <td headers="predef_n">SourceFile</td> 2410 </tr> 2411 <tr> 2412 <td headers="predef_i" align="right">18</td> 2413 <td headers="predef_c">Class</td> 2414 <td headers="predef_n">EnclosingMethod</td> 2415 </tr> 2416 <tr> 2417 <td headers="predef_i" align="right">19</td> 2418 <td headers="predef_c">C,F,M</td> 2419 <td headers="predef_n">Signature</td> 2420 </tr> 2421 <tr> 2422 <td headers="predef_i" align="right">20</td> 2423 <td headers="predef_c">C,F,M</td> 2424 <td headers="predef_n">Deprecated</td> 2425 </tr> 2426 <tr> 2427 <td headers="predef_i" align="right">21</td> 2428 <td headers="predef_c">C,F,M</td> 2429 <td headers="predef_n">RuntimeVisibleAnnotations</td> 2430 </tr> 2431 <tr> 2432 <td headers="predef_i" align="right">22</td> 2433 <td headers="predef_c">C,F,M</td> 2434 <td headers="predef_n">RuntimeInvisibleAnnotations</td> 2435 </tr> 2436 <tr> 2437 <td headers="predef_i" align="right">23</td> 2438 <td headers="predef_c">Class</td> 2439 <td headers="predef_n">InnerClasses</td> 2440 </tr> 2441 <tr> 2442 <td headers="predef_i" align="right">24</td> 2443 <td headers="predef_c">Class</td> 2444 <td headers="predef_n">"class-file version"</td> 2445 </tr> 2446 <tr> 2447 <td headers="predef_i" align="right">17</td> 2448 <td headers="predef_c">Field</td> 2449 <td headers="predef_n">ConstantValue</td> 2450 </tr> 2451 <tr> 2452 <td headers="predef_i" align="right">17</td> 2453 <td headers="predef_c">Method</td> 2454 <td headers="predef_n">Code</td> 2455 </tr> 2456 <tr> 2457 <td headers="predef_i" align="right">18</td> 2458 <td headers="predef_c">Method</td> 2459 <td headers="predef_n">Exceptions</td> 2460 </tr> 2461 <tr> 2462 <td headers="predef_i" align="right">23</td> 2463 <td headers="predef_c">Method</td> 2464 <td headers="predef_n">RuntimeVisibleParameterAnnotations</td> 2465 </tr> 2466 <tr> 2467 <td headers="predef_i" align="right">24</td> 2468 <td headers="predef_c">Method</td> 2469 <td headers="predef_n">RuntimeInvisibleParameterAnnotations</td> 2470 </tr> 2471 <tr> 2472 <td headers="predef_i" align="right">25</td> 2473 <td headers="predef_c">Method</td> 2474 <td headers="predef_n">AnnotationDefault</td> 2475 </tr> 2476 <tr> 2477 <td headers="predef_i" align="right">26</td> 2478 <td headers="predef_c">Method</td> 2479 <td headers="predef_n">MethodParameters</td> 2480 </tr> 2481 <tr> 2482 <td headers="predef_i" align="right">27</td> 2483 <td headers="predef_c">C,F,M</td> 2484 <td headers="predef_n">RuntimeVisibleTypeAnnotations</td> 2485 </tr> 2486 <tr> 2487 <td headers="predef_i" align="right">28</td> 2488 <td headers="predef_c">C,F,M</td> 2489 <td headers="predef_n">RuntimeInvisibleTypeAnnotations</td> 2490 </tr> 2491 <tr> 2492 <td headers="predef_i" align="right">0</td> 2493 <td headers="predef_c">Code</td> 2494 <td headers="predef_n">StackMapTable</td> 2495 </tr> 2496 <tr> 2497 <td headers="predef_i" align="right">1</td> 2498 <td headers="predef_c">Code</td> 2499 <td headers="predef_n">LineNumberTable</td> 2500 </tr> 2501 <tr> 2502 <td headers="predef_i" align="right">2</td> 2503 <td headers="predef_c">Code</td> 2504 <td headers="predef_n">LocalVariableTable</td> 2505 </tr> 2506 <tr> 2507 <td headers="predef_i" align="right">3</td> 2508 <td headers="predef_c">Code</td> 2509 <td headers="predef_n">LocalVariableTypeTable</td> 2510 </tr> 2511 <tr> 2512 <td headers="predef_i" align="right">16</td> 2513 <td headers="predef_c">Code</td> 2514 <td headers="predef_n">(overflow attributes)</td> 2515 </tr> 2516 </table> 2517 <p>Bit 16 is predefined as an indicator of the presence of overflow 2518 attributes for classes, fields, methods, and codes. If an entity 2519 has overflow attributes, it will possess a corresponding count in 2520 an "attr_count" band, and each overflow attribute will be part of a 2521 run of values in an "attr_indexes" band, which specifies the 2522 layouts of the overflow attributes. This processing of overflow 2523 attributes is described more fully in the section <a href= 2524 "#overflow_bits">Attribute Bands</a>.</p> 2525 <p>These predefined attribute indexes determine not only which bit 2526 positions are used to select those attributes, but also the fixed 2527 band order in which the attribute data are transmitted, as 2528 described in the section <a href="#def_order">Attribute Layout Definitions</a>.</p> 2529 <p>Certain bits are predefined to support the five types of 2530 metadata attributes on classes, fields, and methods, 2531 <tt>RuntimeVisibleAnnotations</tt>, 2532 <tt>RuntimeInvisibleAnnotations</tt>, 2533 <tt>RuntimeVisibleTypeAnnotations</tt>, 2534 <tt>RuntimeInvisibleTypeAnnotations</tt>, 2535 <tt>RuntimeVisibleParameterAnnotations</tt>, 2536 <tt>RuntimeInvisibleParameterAnnotations</tt>, and 2537 <tt>AnnotationDefault</tt>. (The last three types apply only to 2538 methods.) The meaning and format of these attributes is defined by 2539 JSR 175.</p> 2540 <p>It is permissible for a compressor to refrain from setting bits 2541 in any flag words except for bit 16, and transmit all attribute 2542 layout indexes explicitly in <tt>class_attr_indexes</tt> or a 2543 similar band. Decompressors are required to process either kind of 2544 occurrence of an attribute index. (It is also permissible, though 2545 useless, for an attribute count to be an explicitly transmitted as 2546 zero.) Compressors are encouraged to make clever choices and clear 2547 bit 16 and set other assigned flag bits when possible.</p> 2548 <p>Note that none of the predefined bits interfere with any present 2549 or future flag bits in the 16-bit flag values stored in the class 2550 file format. However, compressors are free to reuse one of the 2551 low-order 16 bits of the flags word, by binding them to other 2552 attributes, if no file actually sets them.</p> 2553 <p>The <tt>InnerClasses</tt> attribute is treated specially, as 2554 documented in the section <a href="#nested_classes">Nested Classes</a>, and it is an 2555 error for the compressor to emit an attribute definition for it in 2556 the class context. The <tt>Code</tt> attribute is also treated 2557 specially. It is an error to emit an attribute definition for it in 2558 the method context.</p> 2559 <p>This specification does not define how a compressor is informed 2560 of the existence or format of attributes which are not predefined. 2561 It simply assumes that compressors are informed of such attributes, 2562 and it requires that compressors properly transmit this information 2563 to decompressors. As a special case, it is reasonable for any 2564 compressor to transmit an attribute containing no bytes (i.e., of 2565 zero length) as if its layout were known to be the empty 2566 string.</p> 2567 <a name="layouts" id="layouts"></a> <a name="tocAtLaDe" id= 2568 "tocAtLaDe"></a> 2569 <h5>5.5.2. Attribute Layout Definitions</h5> 2570 Attribute layouts govern the compressor as it parses attribute 2571 bodies from class files into collections of scalar values. Layouts 2572 also govern the decompressor as it decodes transmitted bands of 2573 those scalar values, and stores them, correctly formatted, into 2574 class files. For example, when a class file stores an unsigned 2575 integer in two bytes (in big-endian order) in an attribute, the 2576 decompressor uses a layout declaration to this effect, so that it 2577 can take a band element (which is a 32-bit integer that in this 2578 case happens to be less than 65536) and store it correctly into a 2579 class file. The transmission of such an integer is very different 2580 from the transmission of a constant pool reference, even though 2581 they appear as undifferentiated bytes in the class file format. 2582 <p>In what follows, we say that some given element of an attribute 2583 layout <em>governs</em> a scalar value stored in a class file 2584 attribute, if the decompressor must use that element to 2585 reconstitute, into a class file, the representation of that scalar 2586 value. We also say that the given layout element governs the band 2587 in which the scalar value is transmitted.</p> 2588 <p>An attribute layout is defined by a string in a "little 2589 language". The string must be parsed by the decompressor into a 2590 sequence of <em>layout elements</em>, each of which governs the 2591 transmission and storage of attribute values. In particular, the 2592 layout declares the locations of all constant pool references, 2593 allowing their values to be transmitted with appropriate 2594 representations, either as constant pool indexes or else some other 2595 sort of number.</p> 2596 <p>The simplest usable attribute layout would be a sequence of 2597 constant pool reference declarations, intermixed with one-byte 2598 declarations to govern everything else, and compressors are free to 2599 use such layouts to describe attributes. However, more specific 2600 attribute layouts lead to better compression.</p> 2601 <p>Attributes typically contain constant pool references and small 2602 integers. They often contain integers which control the replication 2603 of subsequent patterns. Constant pool references are strongly typed 2604 where possible, and the encoding provision for null references must 2605 be declared also. Small integers which encode flag bits or bytecode 2606 indexes are also declared as such, so that special encoding 2607 techniques may be used on them.</p> 2608 <p>Layout declarations are UTF8 strings formed according to the 2609 following grammar. (This grammar is independent of the grammar 2610 which describes band structure, or any other grammar appearing in 2611 other parts of this specification.)</p> 2612 <pre class="codeblock"> 2613 attribute_layout: 2614 ( layout_element )* | ( callable )+ 2615 layout_element: 2616 ( integral | replication | union | call | reference ) 2617 2618 callable: 2619 '[' body ']' 2620 body: 2621 ( layout_element )+ 2622 2623 integral: 2624 ( unsigned_int | signed_int | bc_index | bc_offset | flag ) 2625 unsigned_int: 2626 uint_type 2627 signed_int: 2628 'S' uint_type 2629 any_int: 2630 ( unsigned_int | signed_int ) 2631 bc_index: 2632 ( 'P' uint_type | 'PO' uint_type ) 2633 bc_offset: 2634 'O' any_int 2635 flag: 2636 'F' uint_type 2637 uint_type: 2638 ( 'B' | 'H' | 'I' | 'V' ) 2639 2640 replication: 2641 'N' uint_type '[' body ']' 2642 2643 union: 2644 'T' any_int (union_case)* '(' ')' '[' (body)? ']' 2645 union_case: 2646 '(' union_case_tag (',' union_case_tag)* ')' '[' (body)? ']' 2647 union_case_tag: 2648 ( numeral | numeral '-' numeral ) 2649 call: 2650 '(' numeral ')' 2651 2652 reference: 2653 reference_type ( 'N' )? uint_type 2654 reference_type: 2655 ( constant_ref | schema_ref | utf8_ref | untyped_ref ) 2656 constant_ref: 2657 ( 'KI' | 'KJ' | 'KF' | 'KD' | 'KS' | 'KQ' | 'KM' | 'KT' | 'KL' ) 2658 schema_ref: 2659 ( 'RC' | 'RS' | 'RD' | 'RF' | 'RM' | 'RI' | 'RY' | 'RB' | 'RN' ) 2660 utf8_ref: 2661 'RU' 2662 untyped_ref: 2663 'RQ' 2664 2665 numeral: 2666 '(' ('-')? (digit)+ ')' 2667 digit: 2668 ( '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ) 2669 2670 </pre> 2671 <p>Each occurrence of an attribute in a class file is associated 2672 (by the compressor) with a corresponding layout definition which 2673 describes accurately the meaning of that attribute's bytes. The 2674 compressor must assign each format element its own band for 2675 transmitting successive values of that format element. In the case 2676 of the predefined attributes, the bands assigned to their layout 2677 elements are defined by name in this specification.</p> 2678 <p>Each value governed by an attribute layout element is converted 2679 by the compressor into a 32-bit value and transmitted as an element 2680 of a band uniquely created for and governed by that layout element. 2681 For <tt>integral</tt> layout elements, the conversion simply 2682 represents the number stored in the class file under the given 2683 type, while <tt>reference</tt> elements convert a local constant 2684 pool reference (local to the class file, that is) into a global, 2685 typed reference within the archive.</p> 2686 <p>Multiple occurrences of the same kind of layout element are 2687 regarded as distinct layout elements. Also, bands are never shared 2688 by layouts. Therefore, every new layout definition transmitted by 2689 the compressor implicitly defines its own set of bands. Reassigning 2690 an previously defined attribute layout to a new index creates a new 2691 set of bands; it does not reuse the previously defined sets of 2692 bands.</p> 2693 <p>If the compressor defines new attributes, it must also create 2694 the bands they govern. It must transmit these bands, immediately 2695 after the place reserved in the band grammar for predefined 2696 attributes (at the end of <tt>class_attr_bands</tt>, <tt>field_attr_bands</tt>, 2697 <tt>method_attr_bands</tt>, or <tt>code_attr_bands</tt>). The 2698 ordering of these bands must correspond to the definition order of 2699 the attribute layout elements that govern them. In this way, the 2700 decompressor will be able to find those attribute values.</p> 2701 <a name="def_order" id="def_order"></a> 2702 <p>The <em>definition order</em> of two layout elements in the same 2703 attribute layout string corresponds to their order of occurrence 2704 within that string. The definition order of two layout elements not 2705 in the same attribute layout string corresponds to the index order 2706 of their layout definitions in the <tt>attr_definition_layout</tt> 2707 band. (That is, bands for layouts with lower indexes precede bands 2708 for layouts of the same context type but with higher indexes. This 2709 is true even if the lower-indexed layout happens to be defined 2710 later in the <tt>attr_definition_layout</tt> band.) Note that the 2711 bands governed by predefined attributes appear to follow such an 2712 ordering also. However, the bands of predefined class attributes 2713 precede all the other class attribute bands, and likewise for 2714 fields, methods, and code attributes.</p> 2715 <p>Integer values stored in attributes are sized as 1, 2, or 4 2716 bytes, depending on the use of the format character 'B', 'H', or 2717 'I', respectively. A integer type is normally unsigned but prefixed 2718 with 'S' becomes signed. This signing governs the lengthening of 2719 1-byte and 2-byte types to 32-bit values (either sign extension or 2720 zero filling). It also determines the primary encoding used to 2721 transmit the 32-bit values. Because all integers stored in class 2722 files are "big-endian", all integral format elements refer to 2723 integers coded with higher-order bits in earlier bytes.</p> 2724 <p><tt>Integral</tt> layouts (i.e., those elements under the 2725 <tt>integral</tt> nonterminal) govern signed or unsigned integer 2726 values. Integral layouts whose declarations include the 'P' or 'O' 2727 characters use special primary encodings (BCI5 or BRANCH5) as 2728 described below. Any other integral layouts whose declarations 2729 include the 'S' character govern bands with a primary encoding of 2730 SIGNED5. Unsigned integer and flag layout elements govern bands 2731 with a primary encoding of UNSIGNED5, except that the integer 2732 layout 'B' (unsigned byte) governs a band with a primary encoding 2733 of BYTE1.</p> 2734 <p>(Note that there is no special encoding for signed bytes. If an 2735 attribute contains a signed byte field, it may be just as well to 2736 treat that field as if it were unsigned, and give it a plain 'B' 2737 layout element. Besides completeness, the 'SB' layout is intended 2738 to allow small-magnitude one-byte integers to be transmitted using 2739 a byte alphabet in which sign bits are rare. This is desirable when 2740 the post-pass compressor uses Huffman coding to represent bytes; 2741 such codings perform best when a consistent byte alphabet is 2742 presented to the compressor.)</p> 2743 <p>A stored bytecode index is declared with the layout prefix 'P'. 2744 This layout element may only be used on methods or codes. Any 2745 number may be stored in a bytecode index. However, before the 2746 stored numbers are transmitted as band elements, they are 2747 renumbered in the expectation that byte positions not on 2748 instruction boundaries will be rare.</p> 2749 <a name="bci_psc_ref" id="bci_psc_ref"></a> <a name= 2750 "bci_renumbering" id="bci_renumbering"></a> 2751 <p>The <em>BCI renumbering</em> compactly indexes instruction 2752 boundaries, and also provides a coding (somewhat less compact) for 2753 all other 32-bit integers, such as the addresses of bytes inside 2754 instructions or outside the bounds of the bytecodes. In particular, 2755 the first byte of the first instruction is numbered zero, the first 2756 byte of the second instruction is numbered one, and so on through 2757 all instructions. The byte position one past the last instruction 2758 is numbered with the next number (the number of instructions). The 2759 second byte of the first multibyte instruction is numbered with the 2760 next number, which is one more than the number of all instructions. 2761 All remaining unnumbered bytes are assigned subsequent numbers, 2762 without any further disturbances of ordering. For large enough 2763 positive numbers, and for negative numbers, the renumbering is the 2764 identity function.</p> 2765 <p>For purposes of locating instruction boundaries for BCI 2766 renumbering, the _wide bytecode (0xc4) is taken to be part of the 2767 following instruction, whose format it helps determine. If the 2768 compressor transmits byte_escape (254) or ref_escape (253) 2769 pseudo-instructions, the decompressor must accept the bytecode 2770 sequences produced by each of these instructions as integral 2771 instructions, when computing BCI renumberings. Thus, there will be 2772 an instruction boundary for each byte in bc_codes (except _wide 2773 bytecodes), plus an extra boundary for each "aload_0_xxx" variation 2774 (such as "aload_0_getstatic_this"), because these pseudo-opcodes 2775 expand to pairs of bytecode instructions.</p> 2776 <p>Please see the Appendix section <a href= 2777 "#bci_psc">Representation of Byte Offsets</a> for pseudo-code explaining this concept.</p> 2778 <p>If the layout element is prefixed by 'P' and not 'PO', then the 2779 renumbered bytecode index is transmitted. This renumbering is 2780 called the <em>bytecode index renumbering</em>. The primary 2781 encoding for bands containing bytecode indexes is BCI5.</p> 2782 <p>Here is an example of how this works. Imagine a method with 20 2783 bytes of bytecode data and five instructions, at the following 2784 positions: <tt>{ 0, 4, 6, 10, 17 }</tt>. BCI renumbering translates 2785 these particular numbers compactly to <tt>[0..4]</tt>. More 2786 completely, BCI renumbering translates <tt>[0..20]</tt> to the 2787 numbers <tt>{ 0, 6, 7, 8, 1, 9, 2, 10, 11, 12, 3, 13, 14, 15, 16, 2788 17, 18, 4, 19, 20, 5 }</tt>, and anything outside the range 2789 <tt>[0..20]</tt> stays the same after BCI renumbering. If a 2790 attribute of this method has a 'P' layout element, and has the 2791 number 6 stored in the class file, the number 2 will be 2792 transmitted, since 6 is the offset of the third instruction.</p> 2793 <p>If the layout prefix is 'PO', the previous layout element must 2794 also have been a bytecode index of layout type 'P' or 'PO'. (There 2795 must not be intervening structure, such as brackets '[' or ']'.) In 2796 this case, the value transmitted in the band governed by the 'PO' 2797 element is the difference between the renumbered bytecode index 2798 governed by the current 'PO' element, and the renumbered bytecode 2799 index governed by the previous 'P' or 'PO' element. (In the case of 2800 a previous 'P' element, this is in fact the value transmitted at 2801 the corresponding position in the previous band.)</p> 2802 <p>The 'PO' layout elements govern the same kind of attribute data 2803 as 'P' elements, but they use an encoding which expects that 2804 adjacent bytecode indexes are correlated. This renumbering, 2805 including a difference with the previous element, is called the 2806 <em>bytecode offset renumbering</em> The primary encoding for bands 2807 containing bytecode offsets is BRANCH5. This encoding is used even 2808 if the layout element contains the 'S' or the 'B' character.</p> 2809 <p>A bytecode offset is declared with the layout prefix 'O'. This 2810 layout element must immediately follow a previous bytecode index 2811 element (with prefix 'P' and not 'PO'). Any value governed by this 2812 layout element is regarded as an offset, which when applied to the 2813 corresponding previously stored bytecode index, produces another 2814 bytecode index. That is, both the previous value and the sum of the 2815 previous value and the current value are expected to refer to 2816 instruction boundaries. As with the 'PO' layout, the value 2817 transmitted is the difference of the two renumbered bytecode 2818 indexes. Bands governed by 'PO' layouts contain bytecode offsets, 2819 and use the BRANCH5 primary encoding. Unlike the 'PO' layout, the 2820 stored value governed by an 'O' layout is the difference between 2821 two bytecode indexes.</p> 2822 <p>Thus, bands governed by both 'O' and 'PO' layouts contain 2823 bytecode offsets, and use BRANCH5 to encode those offsets. But 2824 attribute values governed by both 'P' and 'PO' layouts store 2825 absolute bytecode indexes; only 'O' layouts govern stored bytecode 2826 offsets. The stored offsets are treated as unsigned fields in the 2827 class file unless the 'S' character is present. By contrast, stored 2828 indexes are always treated as unsigned fields.</p> 2829 <p>If the preceding example attribute for a 20-byte method also has 2830 a 'PO' layout element following its 'P' element, and the number 20 2831 is stored in the class file, the number to be transmitted is found 2832 by renumbering 20 to 5, and then subtracting the previous 2833 transmitted number (5-2). The number 3 will therefore be 2834 transmitted. If instead the stored number is 7 (a BCI inside the 2835 instruction at position 6), the transmitted number will be (10-2) 2836 or 8. The same transmitted values (3, 8), if governed by an 'O' 2837 layout element instead of 'PO', would correspond to stored values 2838 of 14 (20-6) and 1 (7-6), instead of 20 and 7.</p> 2839 <p>A flag element (with prefix 'F') encodes integer values which 2840 are expected to encode short array of bits, rather than arithmetic 2841 values. The bits are not required to be interpreted as access 2842 modifiers. The primary encoding for bands transmitting flag layout 2843 elements is UNSIGNED5, except that 'FB' layouts use a primary 2844 encoding of BYTE1.</p> 2845 <p>Integral values transmitted under the 'V' format character 2846 instead of 'B', 'H', or 'I' occupy no bytes at all in the class 2847 file attribute. These layout elements allow the decompressor to use 2848 counts or tags to control transmission without having them appear 2849 directly in class file attributes. For example, consider an 2850 attribute which is an array of bytes that is not self-sizing but 2851 expands to fill the byte-count mentioned in the attribute header in 2852 the class file. Such an attribute might have a layout specification 2853 of 'NV[B]'. The compressor would be responsible to decide which 2854 values to transmit for a 'V' layout element. (Such decisions would 2855 have to make use of detailed information about attribute formats 2856 that is not part of this specification.) In all cases, the 2857 decompressor must respect these values (when used as counts or 2858 tags) but must not store them in the class file.</p> 2859 <p>A <em>replication</em> is introduced by a prefix 'N', which is 2860 followed by an integer element called the <em>replication 2861 count</em>, and by then a series of elements, called the 2862 <em>replication body</em>, enclosed in square brackets. The 2863 attribute data governed by this layout consists of a replication 2864 count followed by an array of data counted by the replication 2865 count. Each array element is governed by the layouts in the 2866 replication body.</p> 2867 <p>A replication count layout element governs a band transmitting 2868 the replication counts, which has a primary encoding of UNSIGNED5 2869 (or BYTE1, if the layout starts with 'NB'). The bands governed by 2870 the corresponding replication body may be sized by summing the 2871 values transmitted in the band containing the counts.</p> 2872 <p>A <em>union</em> is introduced by a prefix 'T', which is 2873 followed by an integer element called the <em>union tag</em>, and 2874 by then a series of labeled, bracketed groups of elements, called 2875 the <em>union cases</em>. (The numerals can have any number of 2876 digits, but their arithmetic values are truncated to 32-bit 2877 integers before being compared with band values, which also are 32 2878 bits in size.) Each label but the last consists of one or more 2879 parenthesized, possibly signed decimal numerals, called <em>union 2880 tags</em>. The last label (which is the default case) must be an 2881 empty pair of parentheses. (No union may contain two occurrences of 2882 the same case tag.) The attribute data governed by this layout 2883 consists of an integral tag value followed by data whose format is 2884 determined by the tag. The data following the tag is governed by 2885 the (unique) union case whose label matches the tag's value, or 2886 else the default case. The bands governed by each union case may be 2887 sized by counting the number of values in the band governed by the 2888 tag's layout. As with plain integral bands, the primary encoding of 2889 union tag band is SIGNED5, BYTE1, or UNSIGNED5, depending on 2890 whether the layout contains an 'S' character, is 'TB', or 2891 otherwise.</p> 2892 <p>In a union tag, two numerals separated by a hyphen specify an 2893 inclusive range. The second number must be greater than the first. 2894 This is an abbreviation for the list of all numerals from the first 2895 to the second, inclusive. The layout is treated exactly as if the 2896 abbreviation were replaced by the complete list.</p> 2897 <p>Constant pool references in an attribute may be typed strongly, 2898 and transmitted as indexes into one of the archive's constant 2899 pools. The layout types beginning with 'KI', 'KJ', 'KF', 'KD', and 2900 'KS' must govern stored indexes in the local constant pool to 2901 constants of type integer, long, float, double, and string. The 2902 layout types beginnig 'KM' and 'KT' govern indexes to constants of 2903 type MethodHandle and MethodType. Likewise, the layout types 2904 beginning with 'RC', 'RS', 'RD', 'RF', 'RM', 'RI', and 'RU' must 2905 govern stored indexes in the local constant pool to symbols of type 2906 class, signature, descriptor (pair of name and type), field 2907 reference, method reference, interface method reference, and UTF8 2908 string. The layout type 'RY' governs indexes to invokedynamic 2909 descriptors, while the type 'RB' governs indexes to bootstrap 2910 method specifiers (which are elements of the 2911 <tt>BootstrapMethods</tt> attribute, not of the constant pool). All 2912 these references are transmitted as 32-bit indexes into the 2913 corresponding global constant pools, in bands with primary encoding 2914 of UNSIGNED5. (This is true even of layouts which contain 'B'.) See 2915 table below.</p> 2916 <p>Note that signature references (layout 'RS') are identical to 2917 Utf8 references (layout 'RU') within a class file, but lead to 2918 different coding tactics in the archive file, since the 2919 <tt>cp_Utf8</tt> and <tt>cp_Signature</tt> constant pools have 2920 independent indexes and are transmitted differently.</p> 2921 <p>The layout elements beginning 'KQ' may only occur in attributes 2922 on fields. They refer to constants in a constant pool whose 2923 identity is determined by the field's signature. (This layout 2924 element is probably useful only for <tt>ConstantValue</tt> 2925 attributes, which are predefined.) The following table gives field 2926 signatures legal for use with 'KQ' layouts, and the corresponding 2927 constant pools in which the corresponding stored references must be 2928 found.</p> 2929 <table border="1" summary= 2930 "field signatures for use with KQ layouts"> 2931 <tr align="center"> 2932 <th id="kq_f">Field Signature</th> 2933 <th id="kq_c">'KQ' Constant Pool</th> 2934 </tr> 2935 <tr> 2936 <td headers="kq_f">B</td> 2937 <td headers="kq_c">cp_Int</td> 2938 </tr> 2939 <tr> 2940 <td headers="kq_f">S</td> 2941 <td headers="kq_c">cp_Int</td> 2942 </tr> 2943 <tr> 2944 <td headers="kq_f">C</td> 2945 <td headers="kq_c">cp_Int</td> 2946 </tr> 2947 <tr> 2948 <td headers="kq_f">Z</td> 2949 <td headers="kq_c">cp_Int</td> 2950 </tr> 2951 <tr> 2952 <td headers="kq_f">I</td> 2953 <td headers="kq_c">cp_Int</td> 2954 </tr> 2955 <tr> 2956 <td headers="kq_f">J</td> 2957 <td headers="kq_c">cp_Long</td> 2958 </tr> 2959 <tr> 2960 <td headers="kq_f">F</td> 2961 <td headers="kq_c">cp_Float</td> 2962 </tr> 2963 <tr> 2964 <td headers="kq_f">D</td> 2965 <td headers="kq_c">cp_Double</td> 2966 </tr> 2967 <tr> 2968 <td headers="kq_f">Ljava/lang/String;</td> 2969 <td headers="kq_c">cp_String</td> 2970 </tr> 2971 <tr> 2972 <td headers="kq_f">Ljava/lang/Class;</td> 2973 <td headers="kq_c">cp_Class</td> 2974 </tr> 2975 </table> 2976 <p>Three additional layout types transmit indexes into constant 2977 pool groups, instead of individual constant pools. They may be used 2978 when the compressor elects to use a layout which has references 2979 that are not strongly typed. The combined type 'KL' may be used for 2980 any index that refers to a valid operand of the 'ldc' instruction, 2981 and the transmitted indexes will be renumbered relative to the 2982 <tt>cp_LoadableValue</tt> pool group. Similarly, the combined 2983 layout type 'RN' may be used for any index that refers to a valid 2984 operand of any of the 'get' or 'invoke' instructions (except 2985 'invokedynamic'), and these indexes will renumbered relative to the 2986 <tt>cp_AnyMember</tt> pool group.</p> 2987 <p>Finally, if a constant pool reference cannot be typed at all, 2988 the compressor must use an <tt>untyped_ref</tt> ('RQ'), which 2989 transmits an index into the comprehensive constant pool group 2990 <tt>cp_All</tt>. For example, all the elements of the 2991 <tt>cp_Utf8</tt> pool are numbered the same in the 'RQ' and 'RU' 2992 layouts. But the first element (element zero) of the 2993 <tt>cp_Int</tt> pool is numbered, for untyped references, as 2994 <tt>cp_Utf8_count</tt>, and the first element of the 2995 <tt>cp_Float</tt> pool is numbered, for untyped references, as 2996 <tt>cp_Utf8_count+cp_Int_count</tt>.</p> 2997 <p>If a compressor is faced with an attribute which contains a 2998 constant pool index of an unexpected type, it may either refuse to 2999 transmit the attribute, or elect to transmit the attribute under a 3000 relaxed layout definition using 'RQ' or 'RQN' elements instead of 3001 more strongly-typed elements. (If the unexpected type is a loadable 3002 constant or member reference, the compressor may elect to use 'RN' 3003 or 'KL' elements instead.) Decompressors are required to honor all 3004 legal layout definitions transmitted by compressors, even if they 3005 might produce illegally formatted class files. (In an extreme case, 3006 a compressor may elect to transmit a class file as if it were a 3007 resource file, obtaining no class-specific compression, but 3008 preserving unusually formatted attributes with bit-for-bit 3009 accuracy.)</p> 3010 <p>If a <tt>reference</tt> layout type includes the character 'N', 3011 all band values encoding constant pool entries are incremented by 3012 one, and the null value is encoded as zero. Otherwise, the null 3013 value is encoded as negative one (-1).</p> 3014 <p>The effect on primary band encodings of the rules given above 3015 may be summarized as a list of prioritized rules for layout 3016 elements, where the first applicable rule determines the 3017 encoding:</p> 3018 <ul> 3019 <li>If the layout contains 'O', use BRANCH5.</li> 3020 <li>Otherwise, if the layout contains 'P', use BCI5.</li> 3021 <li>Otherwise, if the layout contains 'S' but not 'KS' or 'RS', use 3022 SIGNED5.</li> 3023 <li>Otherwise, if the layout contains 'B' but not 'RB', use 3024 BYTE1.</li> 3025 <li>For all other layouts use UNSIGNED5.</li> 3026 </ul> 3027 <p>Here is a table summarizing bands and encodings for various 3028 layout elements. (Not all possible combinations of types and 3029 integer sizes are shown.)</p> 3030 <table border="1" summary= 3031 "summary of bands and encodings for various layout elements"> 3032 <tr align="center"> 3033 <th id="layout_l">Layout<br /> 3034 Element</th> 3035 <th id="layout_s">Stored<br /> 3036 Value</th> 3037 <th id="layout_t">Transmitted<br /> 3038 Value</th> 3039 <th id="layout_p">Primary<br /> 3040 Encoding</th> 3041 </tr> 3042 <tr> 3043 <td headers="layout_l">B</td> 3044 <td headers="layout_s">u1</td> 3045 <td headers="layout_t">x</td> 3046 <td headers="layout_p">BYTE1</td> 3047 </tr> 3048 <tr> 3049 <td headers="layout_l">FB</td> 3050 <td headers="layout_s">u1</td> 3051 <td headers="layout_t">x</td> 3052 <td headers="layout_p">BYTE1</td> 3053 </tr> 3054 <tr> 3055 <td headers="layout_l">SB</td> 3056 <td headers="layout_s">u1</td> 3057 <td headers="layout_t">(byte)x</td> 3058 <td headers="layout_p">SIGNED5</td> 3059 </tr> 3060 <tr> 3061 <td headers="layout_l">H</td> 3062 <td headers="layout_s">u2</td> 3063 <td headers="layout_t">x</td> 3064 <td headers="layout_p">UNSIGNED5</td> 3065 </tr> 3066 <tr> 3067 <td headers="layout_l">FH</td> 3068 <td headers="layout_s">u2</td> 3069 <td headers="layout_t">x</td> 3070 <td headers="layout_p">UNSIGNED5</td> 3071 </tr> 3072 <tr> 3073 <td headers="layout_l">SH</td> 3074 <td headers="layout_s">u2</td> 3075 <td headers="layout_t">(short)x</td> 3076 <td headers="layout_p">SIGNED5</td> 3077 </tr> 3078 <tr> 3079 <td headers="layout_l">I</td> 3080 <td headers="layout_s">u4</td> 3081 <td headers="layout_t">x</td> 3082 <td headers="layout_p">UNSIGNED5</td> 3083 </tr> 3084 <tr> 3085 <td headers="layout_l">FI</td> 3086 <td headers="layout_s">u4</td> 3087 <td headers="layout_t">x</td> 3088 <td headers="layout_p">UNSIGNED5</td> 3089 </tr> 3090 <tr> 3091 <td headers="layout_l">SI</td> 3092 <td headers="layout_s">u4</td> 3093 <td headers="layout_t">x</td> 3094 <td headers="layout_p">SIGNED5</td> 3095 </tr> 3096 <tr> 3097 <td headers="layout_l">PH</td> 3098 <td headers="layout_s">u2</td> 3099 <td headers="layout_t">renumber_bci(x)</td> 3100 <td headers="layout_p">BCI5</td> 3101 </tr> 3102 <tr> 3103 <td headers="layout_l">POH</td> 3104 <td headers="layout_s">u2</td> 3105 <td headers="layout_t">renumber_bci(x) - renumber_bci(x0)</td> 3106 <td headers="layout_p">BRANCH5</td> 3107 </tr> 3108 <tr> 3109 <td headers="layout_l">OH</td> 3110 <td headers="layout_s">u2</td> 3111 <td headers="layout_t">renumber_bci(x0+x) - renumber_bci(x0)</td> 3112 <td headers="layout_p">BRANCH5</td> 3113 </tr> 3114 <tr> 3115 <td headers="layout_l">NB[...]</td> 3116 <td headers="layout_s">u1</td> 3117 <td headers="layout_t">x <em>(also serves as size count)</em></td> 3118 <td headers="layout_p">BYTE1</td> 3119 </tr> 3120 <tr> 3121 <td headers="layout_l">NH[...]</td> 3122 <td headers="layout_s">u2</td> 3123 <td headers="layout_t">x <em>(also serves as size count)</em></td> 3124 <td headers="layout_p">UNSIGNED5</td> 3125 </tr> 3126 <tr> 3127 <td headers="layout_l">NI[...]</td> 3128 <td headers="layout_s">u4</td> 3129 <td headers="layout_t">x <em>(also serves as size count)</em></td> 3130 <td headers="layout_p">UNSIGNED5</td> 3131 </tr> 3132 <tr> 3133 <td headers="layout_l">TB...</td> 3134 <td headers="layout_s">u1</td> 3135 <td headers="layout_t">x</td> 3136 <td headers="layout_p">BYTE1</td> 3137 </tr> 3138 <tr> 3139 <td headers="layout_l">TSB...</td> 3140 <td headers="layout_s">u1</td> 3141 <td headers="layout_t">(byte)x</td> 3142 <td headers="layout_p">SIGNED5</td> 3143 </tr> 3144 <tr> 3145 <td headers="layout_l">TH...</td> 3146 <td headers="layout_s">u2</td> 3147 <td headers="layout_t">x</td> 3148 <td headers="layout_p">UNSIGNED5</td> 3149 </tr> 3150 <tr> 3151 <td headers="layout_l">TSH...</td> 3152 <td headers="layout_s">u2</td> 3153 <td headers="layout_t">(short)x</td> 3154 <td headers="layout_p">SIGNED5</td> 3155 </tr> 3156 <tr> 3157 <td headers="layout_l">KIB</td> 3158 <td headers="layout_s">u1</td> 3159 <td headers="layout_t">indexOf(lcp[x], cp_Int)</td> 3160 <td headers="layout_p">UNSIGNED5</td> 3161 </tr> 3162 <tr> 3163 <td headers="layout_l">KIH</td> 3164 <td headers="layout_s">u2</td> 3165 <td headers="layout_t">indexOf(lcp[x], cp_Int)</td> 3166 <td headers="layout_p">UNSIGNED5</td> 3167 </tr> 3168 <tr> 3169 <td headers="layout_l">KII</td> 3170 <td headers="layout_s">u4</td> 3171 <td headers="layout_t">indexOf(lcp[x], cp_Int)</td> 3172 <td headers="layout_p">UNSIGNED5</td> 3173 </tr> 3174 <tr> 3175 <td headers="layout_l">KINH</td> 3176 <td headers="layout_s">u2</td> 3177 <td headers="layout_t">1+indexOf(lcp[x], cp_Int)</td> 3178 <td headers="layout_p">UNSIGNED5</td> 3179 </tr> 3180 <tr> 3181 <td headers="layout_l">KJH</td> 3182 <td headers="layout_s">u2</td> 3183 <td headers="layout_t">indexOf(lcp[x], cp_Long)</td> 3184 <td headers="layout_p">UNSIGNED5</td> 3185 </tr> 3186 <tr> 3187 <td headers="layout_l">KFH</td> 3188 <td headers="layout_s">u2</td> 3189 <td headers="layout_t">indexOf(lcp[x], cp_Float)</td> 3190 <td headers="layout_p">UNSIGNED5</td> 3191 </tr> 3192 <tr> 3193 <td headers="layout_l">KDH</td> 3194 <td headers="layout_s">u2</td> 3195 <td headers="layout_t">indexOf(lcp[x], cp_Double)</td> 3196 <td headers="layout_p">UNSIGNED5</td> 3197 </tr> 3198 <tr> 3199 <td headers="layout_l">KSH</td> 3200 <td headers="layout_s">u2</td> 3201 <td headers="layout_t">indexOf(lcp[x], cp_String)</td> 3202 <td headers="layout_p">UNSIGNED5</td> 3203 </tr> 3204 <tr> 3205 <td headers="layout_l">KQH</td> 3206 <td headers="layout_s">u2</td> 3207 <td headers="layout_t">indexOf(lcp[x], cp_FieldSpecific)</td> 3208 <td headers="layout_p">UNSIGNED5</td> 3209 </tr> 3210 <tr> 3211 <td headers="layout_l">KMH</td> 3212 <td headers="layout_s">u2</td> 3213 <td headers="layout_t">indexOf(lcp[x], cp_MethodHandle)</td> 3214 <td headers="layout_p">UNSIGNED5</td> 3215 </tr> 3216 <tr> 3217 <td headers="layout_l">KTH</td> 3218 <td headers="layout_s">u2</td> 3219 <td headers="layout_t">indexOf(lcp[x], cp_MethodType)</td> 3220 <td headers="layout_p">UNSIGNED5</td> 3221 </tr> 3222 <tr> 3223 <td headers="layout_l">KLH</td> 3224 <td headers="layout_s">u2</td> 3225 <td headers="layout_t">indexOf(lcp[x], cp_LoadableValue)</td> 3226 <td headers="layout_p">UNSIGNED5</td> 3227 </tr> 3228 <tr> 3229 <td headers="layout_l">RCH</td> 3230 <td headers="layout_s">u2</td> 3231 <td headers="layout_t">indexOf(lcp[x], cp_Class)</td> 3232 <td headers="layout_p">UNSIGNED5</td> 3233 </tr> 3234 <tr> 3235 <td headers="layout_l">RSH</td> 3236 <td headers="layout_s">u2</td> 3237 <td headers="layout_t">indexOf(lcp[x], cp_Signature)</td> 3238 <td headers="layout_p">UNSIGNED5</td> 3239 </tr> 3240 <tr> 3241 <td headers="layout_l">RDH</td> 3242 <td headers="layout_s">u2</td> 3243 <td headers="layout_t">indexOf(lcp[x], cp_Descr)</td> 3244 <td headers="layout_p">UNSIGNED5</td> 3245 </tr> 3246 <tr> 3247 <td headers="layout_l">RFH</td> 3248 <td headers="layout_s">u2</td> 3249 <td headers="layout_t">indexOf(lcp[x], cp_Field)</td> 3250 <td headers="layout_p">UNSIGNED5</td> 3251 </tr> 3252 <tr> 3253 <td headers="layout_l">RMH</td> 3254 <td headers="layout_s">u2</td> 3255 <td headers="layout_t">indexOf(lcp[x], cp_Method)</td> 3256 <td headers="layout_p">UNSIGNED5</td> 3257 </tr> 3258 <tr> 3259 <td headers="layout_l">RIH</td> 3260 <td headers="layout_s">u2</td> 3261 <td headers="layout_t">indexOf(lcp[x], cp_Imethod)</td> 3262 <td headers="layout_p">UNSIGNED5</td> 3263 </tr> 3264 <tr> 3265 <td headers="layout_l">RUH</td> 3266 <td headers="layout_s">u2</td> 3267 <td headers="layout_t">indexOf(lcp[x], cp_Utf8)</td> 3268 <td headers="layout_p">UNSIGNED5</td> 3269 </tr> 3270 <tr> 3271 <td headers="layout_l">RQH</td> 3272 <td headers="layout_s">u2</td> 3273 <td headers="layout_t">indexOf(lcp[x], cp_All)</td> 3274 <td headers="layout_p">UNSIGNED5</td> 3275 </tr> 3276 <tr> 3277 <td headers="layout_l">RQNH</td> 3278 <td headers="layout_s">u2</td> 3279 <td headers="layout_t">1+indexOf(lcp[x], cp_All)</td> 3280 <td headers="layout_p">UNSIGNED5</td> 3281 </tr> 3282 <tr> 3283 <td headers="layout_l">RQNI</td> 3284 <td headers="layout_s">u4</td> 3285 <td headers="layout_t">1+indexOf(lcp[x], cp_All)</td> 3286 <td headers="layout_p">UNSIGNED5</td> 3287 </tr> 3288 <tr> 3289 <td headers="layout_l">RYH</td> 3290 <td headers="layout_s">u2</td> 3291 <td headers="layout_t">indexOf(lcp[x], cp_InvokeDynamic)</td> 3292 <td headers="layout_p">UNSIGNED5</td> 3293 </tr> 3294 <tr> 3295 <td headers="layout_l">RBH</td> 3296 <td headers="layout_s">u2</td> 3297 <td headers="layout_t">indexOf(class.BootstrapMethods[x], 3298 cp_BootstrapMethod)</td> 3299 <td headers="layout_p">UNSIGNED5</td> 3300 </tr> 3301 <tr> 3302 <td headers="layout_l">RNH</td> 3303 <td headers="layout_s">u2</td> 3304 <td headers="layout_t">indexOf(lcp[x], cp_AnyMember)</td> 3305 <td headers="layout_p">UNSIGNED5</td> 3306 </tr> 3307 </table> 3308 <p>Here, the variable <em>x</em> names a value stored in the 3309 attribute, governed by the layout element. The variable <em>x0</em> 3310 names the stored value governed by the immediately previous layout 3311 element, which must have begun with 'P'. The expression 3312 <em>renumber_bci(x)</em> denotes the renumbering of a bytecode 3313 index <em>x</em> to shorten references to instruction boundaries, 3314 as described above. The expression <em>lcp[x]</em> denotes a local 3315 constant pool reference, with index <em>x</em>, or a distinct null 3316 value if <em>x</em> is zero.</p> 3317 <p>The expression <em>class.BootstrapMethods[x]</em> denotes an 3318 element of the <tt>BootstrapMethods</tt> attribute of the current 3319 class. This attribute contains additional complex constants 3320 required by <tt>CONSTANT_InvokeDynamic</tt> constant pool 3321 entries.</p> 3322 <p>The expression <em>indexOf(lcp[x], cp)</em> denotes the index 3323 (zero-based) in a Pack200 global constant pool <em>cp</em> of the 3324 constant <em>lcp[x]</em>, which is assumed to be of a type 3325 appropriate to <em>cp</em>. This expression has the value -1 if 3326 <em>lcp[x]</em> has the distinct null value.</p> 3327 <p>Note that a null reference can always be transmitted in a band 3328 containing references, by transmitting the value zero (if the band 3329 is specified to accept nulls) or by transmitting the value -1 3330 (otherwise). The UNSIGNED5 encoding can represent -1 in five 3331 bytes.</p> 3332 <p>The name <em>cp_FieldSpecific</em> refers to a global constant 3333 pool selected by the enclosing field's signature, as described 3334 above.</p> 3335 <a name="tocRecLay" id="tocRecLay"></a> 3336 <h5>5.5.3. Recursive Layouts</h5> 3337 The top-level structure of a layout specification may be a series 3338 of bodies which are independently <em>callable</em> layouts. In 3339 such a case, the attribute data governed by the whole layout 3340 specification is governed by the first body in the sequence of 3341 callables. The other callables can govern data, but they only do 3342 this if they are actually called. The effect is to define a 3343 mutually recursive set of layout specifications, and give control 3344 to the first. Note that callables may not be nested inside any 3345 other syntax. This feature is useful for supporting recursively 3346 structured class file attributes, such as metadata. 3347 <p>A <em>call</em> layout element is a parenthesized signed decimal 3348 numeral <em>N</em>. It refers to the <em>N</em>th <em>callable</em> 3349 in the top-level structure of the layout specification, relative to 3350 the callable in which the call appears. (It is illegal for calls to 3351 appear outside of callables.) We will refer to this callable as the 3352 call's <em>callee</em>.</p> 3353 <p>(For example, the layout element '(2)' calls the second callable 3354 layout after the one in which the call appears. There must be a 3355 matching callee for every callable. A call spelled '(1)' must not 3356 appear in the last callable of a layout, and likewise a call 3357 spelled '(-1)' must not occur in the first callable. Note that the 3358 self-call spelled '(0)' is always legal.)</p> 3359 <p>A <em>call</em> layout element indirectly governs the attribute 3360 data more directly governed by the callable that the layout element 3361 calls. As far as class file format is concerned, the effect is the 3362 same as if the text within the callable's body were substituted 3363 instead of the call.</p> 3364 <p>However, this substitution semantics does not describe the 3365 effect of a call layout element on band structure. A call layout 3366 element does not directly govern any bands, but rather specifies 3367 that the data it indirectly governs is to be transmitted in the 3368 bands governed more directly by the callee.</p> 3369 <p>If a call's callee begins textually later than the call itself, 3370 the call is a <em>forward call</em>. The effect of a forward call 3371 is simply to make the bands of the callee sharable by the call and 3372 any other forward calls to the same callee. For example, the 3373 following layout specification has two bands, the latter of which 3374 transmits data indirectly governed by either of the union cases. 3375 (The default union case governs no bands, so that a tag byte other 3376 than ASCII 'A' or 'B' has no following bytes. Whitespace has been 3377 added to the layout for ease of reading.)</p> 3378 <pre class="codeblock"> 3379 [TB 3380 (65) [(1)] 3381 (66) [(1)] 3382 ( ) [] 3383 ] 3384 [H] 3385 3386 </pre> 3387 <p>A call's callee can also begin textually earlier than the call 3388 itself. Such a call, which must have a spelling of the form '(0)' 3389 or '(-<em>N</em>)', is referred to as a <em>backward call</em>. Its 3390 callee is referred to as a <em>backward callable</em>. (Callables 3391 which are the target of no calls or only of forward calls are not 3392 backward callables; all others are.) Backward calls and callables 3393 introduce the possibility of recursion and looping. Here is an 3394 example of an N-ary tree whose leaves are Utf8 strings preceded by 3395 a zero-byte, and whose internal nodes are counted arrays of tree 3396 nodes preceded by a one-byte: In this example, the callee encloses 3397 the call, for a direct recursion. The layout governs three bands, 3398 under the elements 'TB', 'NH', and 'RUH'.</p> 3399 <pre class="codeblock"> 3400 [TB 3401 (1) [NH[ (0) ]] 3402 (0) [RUH] 3403 ] 3404 3405 </pre> 3406 <p>The sizing of bands governed by such mutually-recursive layouts 3407 is assisted by explicit counts of backward calls, transmitted 3408 before any of the layout's attribute bands, in 3409 <tt>class_attr_calls</tt> and three similar bands, which are 3410 described later.</p> 3411 <a name="tocDeAtLa" id="tocDeAtLa"></a> 3412 <h5>5.5.4. Default Attribute Layouts</h5> 3413 The layout definitions of the predefined attributes are as follows: 3414 <table border="1" summary= 3415 "layout definitions for predefined attributes"> 3416 <tr align="center"> 3417 <th id="predef_attr_layout_c">Context Type</th> 3418 <th id="predef_attr_layout_n">Name</th> 3419 <th id="predef_attr_layout_l">Layout Definition</th> 3420 </tr> 3421 <tr> 3422 <td headers="predef_attr_layout_c">Class</td> 3423 <td headers="predef_attr_layout_n">"class-file version"</td> 3424 <td headers="predef_attr_layout_l"><em>(empty) *(see 3425 note)</em></td> 3426 </tr> 3427 <tr> 3428 <td headers="predef_attr_layout_c">Class</td> 3429 <td headers="predef_attr_layout_n">InnerClasses</td> 3430 <td headers="predef_attr_layout_l"><em>(empty) *(see 3431 note)</em></td> 3432 </tr> 3433 <tr> 3434 <td headers="predef_attr_layout_c">Class</td> 3435 <td headers="predef_attr_layout_n">EnclosingMethod</td> 3436 <td headers="predef_attr_layout_l">RCHRDNH</td> 3437 </tr> 3438 <tr> 3439 <td headers="predef_attr_layout_c">Class</td> 3440 <td headers="predef_attr_layout_n">SourceFile</td> 3441 <td headers="predef_attr_layout_l">RUNH *(see note)</td> 3442 </tr> 3443 <tr> 3444 <td headers="predef_attr_layout_c">Class</td> 3445 <td headers="predef_attr_layout_n">Signature</td> 3446 <td headers="predef_attr_layout_l">RSH</td> 3447 </tr> 3448 <tr> 3449 <td headers="predef_attr_layout_c">Class</td> 3450 <td headers="predef_attr_layout_n">(metadata)</td> 3451 <td headers="predef_attr_layout_l">(see <a href="#md_lo">Metadata Layouts</a>)</td> 3452 </tr> 3453 <tr> 3454 <td headers="predef_attr_layout_c">Class</td> 3455 <td headers="predef_attr_layout_n">Deprecated</td> 3456 <td headers="predef_attr_layout_l"><em>(empty)</em></td> 3457 </tr> 3458 <tr> 3459 <td headers="predef_attr_layout_c">Field</td> 3460 <td headers="predef_attr_layout_n">ConstantValue</td> 3461 <td headers="predef_attr_layout_l">KQH</td> 3462 </tr> 3463 <tr> 3464 <td headers="predef_attr_layout_c">Field</td> 3465 <td headers="predef_attr_layout_n">Signature</td> 3466 <td headers="predef_attr_layout_l">RSH</td> 3467 </tr> 3468 <tr> 3469 <td headers="predef_attr_layout_c">Field</td> 3470 <td headers="predef_attr_layout_n">(metadata)</td> 3471 <td headers="predef_attr_layout_l">(see <a href="#md_lo">Metadata Layouts</a>)</td> 3472 </tr> 3473 <tr> 3474 <td headers="predef_attr_layout_c">Field</td> 3475 <td headers="predef_attr_layout_n">Deprecated</td> 3476 <td headers="predef_attr_layout_l"><em>(empty)</em></td> 3477 </tr> 3478 <tr> 3479 <td headers="predef_attr_layout_c">Method</td> 3480 <td headers="predef_attr_layout_n">Code</td> 3481 <td headers="predef_attr_layout_l"><em>(empty) *(see 3482 note)</em></td> 3483 </tr> 3484 <tr> 3485 <td headers="predef_attr_layout_c">Method</td> 3486 <td headers="predef_attr_layout_n">Exceptions</td> 3487 <td headers="predef_attr_layout_l">NH[RCH]</td> 3488 </tr> 3489 <tr> 3490 <td headers="predef_attr_layout_c">Method</td> 3491 <td headers="predef_attr_layout_n">Signature</td> 3492 <td headers="predef_attr_layout_l">RSH</td> 3493 </tr> 3494 <tr> 3495 <td headers="predef_attr_layout_c">Method</td> 3496 <td headers="predef_attr_layout_n">(metadata)</td> 3497 <td headers="predef_attr_layout_l">(see <a href="#md_lo">Metadata Layouts</a>)</td> 3498 </tr> 3499 <tr> 3500 <td headers="predef_attr_layout_c">Method</td> 3501 <td headers="predef_attr_layout_n">Deprecated</td> 3502 <td headers="predef_attr_layout_l"><em>(empty)</em></td> 3503 </tr> 3504 <tr> 3505 <td headers="predef_attr_layout_c">Method</td> 3506 <td headers="predef_attr_layout_n">MethodParameters</td> 3507 <td headers="predef_attr_layout_l">NB[RUNHFH]</td> 3508 </tr> 3509 <tr> 3510 <td headers="predef_attr_layout_c">Code</td> 3511 <td headers="predef_attr_layout_n">StackMapTable</td> 3512 <td headers="predef_attr_layout_l">(see <a href="#sm_lo">Stack Map Layouts</a>)</td> 3513 </tr> 3514 <tr> 3515 <td headers="predef_attr_layout_c">Code</td> 3516 <td headers="predef_attr_layout_n">LineNumberTable</td> 3517 <td headers="predef_attr_layout_l">NH[PHH]</td> 3518 </tr> 3519 <tr> 3520 <td headers="predef_attr_layout_c">Code</td> 3521 <td headers="predef_attr_layout_n">LocalVariableTable</td> 3522 <td headers="predef_attr_layout_l">NH[PHOHRUHRSHH]</td> 3523 </tr> 3524 <tr> 3525 <td headers="predef_attr_layout_c">Code</td> 3526 <td headers="predef_attr_layout_n">LocalVariableTypeTable</td> 3527 <td headers="predef_attr_layout_l">NH[PHOHRUHRSHH]</td> 3528 </tr> 3529 </table> 3530 <p>The star '*' in the layout definitions of "class-file version", 3531 <tt>InnerClasses</tt>, <tt>SourceFile</tt>, and <tt>Code</tt> 3532 reflects the fact that these attributes are given special 3533 processing. For a class, the "<a href= 3534 "#special_version_number">class-file version</a>" pseudo-attribute 3535 is transmitted as if using the format <tt>VV</tt>, but the 3536 decompressor does not store the result in a class file attribute, 3537 but rather in the class file header. (See the discussion in the section <a href= 3538 "#special_version_number">Attribute Bands</a>.) For a class, the 3539 <tt>InnerClasses</tt> attribute is partially transmitted as if 3540 using the format <tt>NV[RCVTV[(0)[]()[RCNVRUNV]]]</tt>, but the 3541 decompressor processes the received values further before 3542 (possibly) emitting an <tt>InnerClasses</tt> attribute. (See the 3543 discussion in the section <a href="#ic_local_bands">Local InnerClasses Attributes</a>.) When a 3544 <tt>SourceFile</tt> attribute is transmitted using the predefined 3545 layout, a special rule allows it to default to the obvious standard 3546 string. Finally, for a method, the <tt>Code</tt> attribute is 3547 transmitted under the <tt>code_bands</tt>. <!-- 3548 Other known attribute formats: 3549 class SourceID "RUH" 3550 class CompilationID "RUH" 3551 code CharacterRangeTable "NH[PHPOHIIH]" 3552 code CoverageTable "NH[PHHII]" 3553 method Code "HHNI[B]NH[PHPOHPOHRCNH]NH[RUHNI[B]]" 3554 3555 Special compression tactics on attributes: 3556 - SourceFile: demangle class name, remove package, add ".java" 3557 - Code 3558 * NO: (ACC_NATIVE|ACC_ABSTRACT) 3559 * I (# bytes) implicit up to _end marker 3560 * 4 H's (SLHA) treated as one-byte tuple 3561 * handler rows are positively differenced mod code size 3562 --></p> 3563 <a name="sm_lo" id="sm_lo"></a> <a name="tocStMaLa" id= 3564 "tocStMaLa"></a> 3565 <h5>5.5.5. Stack Map Layouts</h5> 3566 There is a predefined attribute layout for the 3567 <tt>StackMapTable</tt> attribute of a <tt>Code</tt> attribute. With 3568 some whitespace and abbreviation added for readability, it is as 3569 follows: 3570 <pre class="codeblock"> 3571 <tt> 3572 [NH[(1)]] 3573 [TB 3574 (64-127) [(2)] 3575 (247) [(1)(2)] 3576 (248-251) [(1)] 3577 (252) [(1)(2)] 3578 (253) [(1)(2)(2)] 3579 (254) [(1)(2)(2)(2)] 3580 (255) [(1)NH[(2)]NH[(2)]] 3581 () [] 3582 ] 3583 [H] 3584 [TB 3585 (7) [RCH] 3586 (8) [PH] 3587 () [] 3588 ] 3589 </tt> 3590 </pre> 3591 <p>The following observations may be deduced by comparing this 3592 layout specification with the class file format specification which 3593 defines the <tt>StackMapTable</tt> attribute. The second callable 3594 describes a <tt>stack_map_frame</tt> structure from the class file 3595 format specification. Within the union in the second callable, the 3596 cases stand for the following <tt>stack_map_frame</tt> union 3597 members, respectively: <tt>same_locals_1_stack_item_frame</tt>, 3598 <tt>same_locals_1_stack_item_extended</tt>, <tt>chop_frame</tt> 3599 (and also <tt>same_frame_extended</tt>), <tt>append_frame</tt> (for 3600 three layout union cases), <tt>full_frame</tt>, and (in the default 3601 layout union case) <tt>same_frame</tt>. The third and fourth 3602 callables describe an <tt>offset_delta</tt> value and a 3603 <tt>verification_type_info</tt> structure from the class file 3604 format specification.</p> 3605 <a name="md_lo" id="md_lo"></a> <a name="tocMetLay" id= 3606 "tocMetLay"></a> 3607 <h5>5.5.6. Metadata Layouts</h5> 3608 The predefined attribute layouts for non-parameter metadata 3609 annotations are the same in all three contexts. With some 3610 whitespace added for readability, the layout is as follows: 3611 <pre class="codeblock"> 3612 <tt> 3613 [NH[(1)]] 3614 [RSH NH[RUH(1)]] 3615 [TB 3616 (66,67,73,83,90) [KIH] 3617 (68) [KDH] 3618 (70) [KFH] 3619 (74) [KJH] 3620 (99) [RSH] 3621 (101) [RSH RUH] 3622 (115) [RUH] 3623 (91) [NH[(0)]] 3624 (64) [RSH [RUH(0)]] 3625 () [] 3626 ] 3627 </tt> 3628 </pre> 3629 Both visible and invisible annotations use this layout. The second 3630 callable describes an <tt>annotation</tt> structure from the 3631 metadata specification. The third callable describes a 3632 <tt>member_value</tt> structure from the metadata specification. 3633 This last callable, all by itself, is used for the 3634 <tt>AnnotationDefault</tt> attribute on methods. Method parameter 3635 annotations (both visible and invisible) are also predefined using 3636 this layout, with a prepended callable to count the number of 3637 parameters: 3638 <pre class="codeblock"> 3639 <tt> 3640 [NB[(1)]] 3641 [NH[(1)]] 3642 [RSH NH[RUH(1)]] 3643 [TB...] 3644 </tt> 3645 </pre> 3646 <br> 3647 Additionally RuntimeVisibleTypeAnnotation and RuntimeInvisibleTypeAnnotation 3648 are predefined, using similar strategies as before, the layouts are as follows: 3649 <pre class="codeblock"> 3650 <tt> 3651 [NH[(1)(2)(3)]] 3652 [TB 3653 (0,1) [B] 3654 (16) [H] 3655 (17,18) [BB] 3656 (19,20,21) ()[] 3657 (22) [B] 3658 (23) [H] 3659 (64,64) [NH[PHOHH]] 3660 (66) [H] 3661 (67,68,69,70) [PH] 3662 (71,72,73,74,75) [PHB] 3663 ()[] ] 3664 [NB[BB]] 3665 [TB 3666 (66,67,73,83,90) [KIH] 3667 (68) [KDH] 3668 (70) [KFH] 3669 (74) [KJH] 3670 (99) [RSH] 3671 (101) [RSH RUH] 3672 (115) [RUH] 3673 (91) [NH[(0)]] 3674 (64) [RSH [RUH(0)]] 3675 () [] 3676 ] 3677 </tt> 3678 </pre> 3679 Both visible and invisible type annotations use the above layout, the 3680 data structures are specified in the Type Annotations JSR-308. The first 3681 callable refers to <tt>target_type</tt> and <tt>target_info</tt> 3682 union structure, the second callable refers to <tt>target_path</tt>, 3683 the third callable refers to <tt>element_values</tt> as described for 3684 regular meta-data layouts. These layouts like the metadata layouts are 3685 predefined in the compressor, and are applicable to Class, Field and Method 3686 info structures. 3687 <a name="tocUnLaUs" id="tocUnLaUs"></a> 3688 <h5>5.5.7. Unusual Layout Usages</h5> 3689 It is possible for the compressor to emit any number of definitions 3690 for the same attribute name. These definitions are assigned 3691 different attribute indexes (and perhaps flag bits), and are 3692 treated as distinct attributes, despite having the same name. If an 3693 attribute is too complex to define in the layout language, each 3694 occurrence of that attribute can be given a separate definition by 3695 the compressor. The minimum requirement is that each layout 3696 accurately declare the size of the corresponding attribute 3697 occurrence, and locate all constant pool references within that 3698 occurrence. <a name="tocSoFiAb" id="tocSoFiAb"></a> 3699 <h4>5.6. Source File Abbreviation</h4> 3700 When a null reference is transmitted in the band governed by the 3701 predefined <tt>SourceFile</tt> attribute, the decompressor is 3702 required to replace it by a reference to a Utf8 string whose 3703 spelling consists of the associated class name string, with the 3704 following modifications made, in order: 3705 <ul> 3706 <li>Every character up to and including the last slash or dot ('/' 3707 or '.') is removed. (This removes any package prefix.)</li> 3708 <li>If there is a character of code 0x2D or lower in the remaining 3709 string, the first such and all following characters are removed. 3710 (This removes any nested class name mangling.)</li> 3711 <li>The suffix characters ".java" are appended.</li> 3712 </ul> 3713 <p>This rule matches the historical behavior of many Java 3714 compilers, and allows the compressor to avoid allocating Utf8 3715 strings for "obvious" derived <tt>SourceFile</tt> names. (If a 3716 compressor needs to transmit an irregular <tt>SourceFile</tt> 3717 attribute with a true null reference, it must use a non-standard 3718 layout.) Here is a table of examples of class names and the 3719 corresponding derived <tt>SourceFile</tt> names.</p> 3720 <table border="1" summary= 3721 "examples of prediction, nonprediction, and misprediction"> 3722 <tr align="center"> 3723 <th id="derived_names_c">Class</th> 3724 <th id="derived_names_s"><tt>SourceFile</tt></th> 3725 </tr> 3726 <tr> 3727 <td headers="derived_names_c">foo</td> 3728 <td headers="derived_names_s">foo.java</td> 3729 </tr> 3730 <tr> 3731 <td headers="derived_names_c">foo/bar</td> 3732 <td headers="derived_names_s">bar.java</td> 3733 </tr> 3734 <tr> 3735 <td headers="derived_names_c">foo/bar$baz</td> 3736 <td headers="derived_names_s">bar.java</td> 3737 </tr> 3738 <tr> 3739 <td headers="derived_names_c">foo/bar#baz#1</td> 3740 <td headers="derived_names_s">bar.java</td> 3741 </tr> 3742 <tr> 3743 <td headers="derived_names_c">foo.bar.baz#1</td> 3744 <td headers="derived_names_s">baz.java</td> 3745 </tr> 3746 </table> 3747 <a name="nested_classes" id="nested_classes"></a> <a name= 3748 "tocNesCla" id="tocNesCla"></a> 3749 <h4>5.7. Nested Classes</h4> 3750 A nested class record is a four-tuple specifying two classes, a 3751 name, and some flags, as documented for the <tt>InnerClasses</tt> 3752 attribute of class files. It is primarily represented in the 3753 Pack200 archive by four bands, whose contents are applied equally 3754 to all class files in the archive. 3755 <pre class="codeblock"> 3756 ic_bands: 3757 *ic_this_class :UDELTA5 [#ic_count] (cp_Class) 3758 *ic_flags :UNSIGNED5 [#ic_count] 3759 *ic_outer_class :DELTA5 [COUNT(1<<16,...)] (null or cp_Class) 3760 *ic_name :DELTA5 [LENGTH(*ic_outer_class)] (null or cp_Utf8) 3761 3762 </pre> 3763 These four-tuples are shared globally, like constant pool entries. 3764 In this specification, they are conventionally written 3765 <tt><C,F,C2,N></tt>, even though they are stored in a 3766 different order in the class file format. As a set, these globally 3767 defined four-tuples are called <tt>ic_All</tt>. There is usually no 3768 explicit linkage from individual classes in the archive to nested 3769 class records. Instead, when extracting a class file from a Pack200 3770 archive, an subset of nested class records may be selected which is 3771 sufficient to describe all nested classes actually mentioned in the 3772 extracted class file's constant pool. For any class file X to be 3773 extracted, this subset will be called <tt>ic_Relevant(X)</tt>, the 3774 <em>relevant subset</em> for X of <tt>ic_All</tt>. The algorithm 3775 for selecting the relevant subset is described in the section <a href= 3776 "#ic_subset_selection">Ordering of Constant Pools</a>. Optionally, the compressor can 3777 specify, for any given class, an adjustment to its relevant subset, 3778 by transmitting a local <tt>InnerClasses</tt> attribute. This also 3779 is described in the section <a href="#ic_local_bands">Local InnerClasses Attributes</a>. 3780 <p>The <tt>ic_this_class</tt> and <tt>ic_flags</tt> bands are both 3781 of length <tt>#ic_count</tt>, and the corresponding elements of 3782 these bands specify, for each tuple, the nested class identity 3783 (represented as a <tt>cp_Class</tt> reference) and the flags 3784 bitmask.</p> 3785 <a name="explicit_outer" id="explicit_outer"></a> 3786 <p>The nested class flag bit at position 16 (as set in the mask 3787 0x00010000) is inside the archive file to indicate if there are 3788 corresponding entries for the tuple in the <tt>ic_outer_class</tt> 3789 and <tt>ic_name</tt> bands. Thus, the length of both of these bands 3790 is the sum of all flag bits at position 16. Typically, only a few 3791 percent of nested classes need to set this bit and specify outer 3792 and name fields explicitly.</p> 3793 <p>If a tuple has an entry in the <tt>ic_outer_class</tt> and 3794 <tt>ic_name</tt> bands, these specify its outer class and simple 3795 name. (They are represented respectively as a possibly null 3796 <tt>cp_Class</tt> reference and a possibly null <tt>cp_Utf8</tt> 3797 reference.) Otherwise, the tuple's outer class and name are said to 3798 be <em>predicted</em>. In this case, they must be correctly 3799 predictable from the name of the nested class itself, by parsing 3800 its spelling.</p> 3801 <a name="icn_psc_ref" id="icn_psc_ref"></a> 3802 <p>A nested class has a <em>bytecode name</em> which names the 3803 class within class files. The spelling of this name, sometimes 3804 called a "mangled name", has extra punctuation signs and perhaps 3805 digits as well as the name of a containing class. If the bytecode 3806 name can be parsed into an outer class and a class name, and this 3807 class and name are identical with the true outer class and class 3808 name of the nested class, then we say the outer class and class 3809 name are <em>predictable</em>.</p> 3810 <p>The extraction of the predictable outer class and class name 3811 must follow the following grammar for class bytecode names, as 3812 applied to the spelling of the nested class name. (This grammar is 3813 independent of the grammar governing band structure, or any other 3814 grammar appearing in other parts of this specification.) The 3815 terminal DOLLAR refers to any character (such as '$' or '#') whose 3816 code is 0x2D or lower. The terminals SLASH refers to the slash or 3817 dot characters '/' or '.', which have the codes 0x2E and 0x2F. The 3818 terminal DIGIT refers to an ASCII decimal digit, one of the ten 3819 character codes from 0x30 to 0x39 inclusive. The terminal LETTER 3820 refers to any other character. That is, it refers to any character 3821 whose code is 0x3A or higher.</p> 3822 <pre class="codeblock"> 3823 bcn: 3824 (bcnCase1 | bcnCase2 | bcnCase3 | bcnCase4) 3825 bcnCase1: 3826 packageQual (namePart)? DOLLAR number 3827 bcnCase2: 3828 packageQual (namePart)? DOLLAR number DOLLAR predictableICName 3829 bcnCase3: 3830 predictableOuter DOLLAR predictableICName 3831 bcnCase4: 3832 packageQual (namePart)? 3833 3834 predictableOuter: 3835 packageQual namePart 3836 predictableICName: 3837 LETTER (LETTER | DIGIT)* 3838 3839 namePart: 3840 (LETTER | DIGIT | DOLLAR)+ 3841 number: 3842 (DIGIT)+ 3843 packageQual: 3844 (namePart SLASH)* 3845 3846 </pre> 3847 <p>This grammar ambiguously divides an arbitrary class name into 3848 several parts, which may include an optional 3849 <em>predictedOuter</em> prefix, an optional 3850 <em>predictedICName</em> suffix, and a optional numeric suffix. Any 3851 ambiguity must be resolved by preferring the alternative cases for 3852 <tt>bcn</tt> nonterminal in the order given. E.g., if 3853 <tt>bcnCase1</tt> matches, it is used, even though either or both 3854 other cases may match also.</p> 3855 <p>The predictable nested class name is the string corresponding to 3856 the <tt>predictableICName</tt> nonterminal, if it was parsed. 3857 Otherwise the predictable nested class name is taken to be 3858 null.</p> 3859 <p>If a <tt>predictableOuter</tt> outer nonterminal is parsed, the 3860 corresponding string is the predictable outer class name. Otherwise 3861 the predictable outer class reference is taken to be null. Note 3862 that if a <tt>number</tt> nonterminal is parsed, no 3863 <tt>predictableOuter</tt> can be parsed. Here are some examples of 3864 prediction, nonprediction, and misprediction:</p> 3865 <table border="1" summary="inner class prediction examples"> 3866 <tr> 3867 <th id="ic_prediction_ic" colspan="2" align="center">Inner Class 3868 Prediction Examples</th> 3869 </tr> 3870 <tr> 3871 <td headers="ic_prediction_ic" align="right">nested class:</td> 3872 <td headers="ic_prediction_ic">member named <tt>Entry</tt> of 3873 <tt>java/util/Map</tt></td> 3874 </tr> 3875 <tr> 3876 <td headers="ic_prediction_ic" align="right">mangled name:</td> 3877 <td headers="ic_prediction_ic"><tt>java/util/Map$Entry</tt></td> 3878 </tr> 3879 <tr> 3880 <td headers="ic_prediction_ic" align="right">outer, name:</td> 3881 <td headers="ic_prediction_ic"><tt>java/util/Map</tt>, 3882 <tt>Entry</tt></td> 3883 </tr> 3884 <tr> 3885 <td headers="ic_prediction_ic" align="center">predictable?</td> 3886 <td headers="ic_prediction_ic">yes (since <tt>Map.Entry</tt> is a 3887 member of <tt>Map</tt>)</td> 3888 </tr> 3889 <tr> 3890 <td headers="ic_prediction_ic"></td> 3891 <td headers="ic_prediction_ic"></td> 3892 </tr> 3893 <tr> 3894 <td headers="ic_prediction_ic" align="right">nested class:</td> 3895 <td headers="ic_prediction_ic">anonymous</td> 3896 </tr> 3897 <tr> 3898 <td headers="ic_prediction_ic" align="right">mangled name:</td> 3899 <td headers="ic_prediction_ic"> 3900 <tt>java/util/AbstractList$1</tt></td> 3901 </tr> 3902 <tr> 3903 <td headers="ic_prediction_ic" align="right">outer, name:</td> 3904 <td headers="ic_prediction_ic"><em>(none)</em>, 3905 <em>(none)</em></td> 3906 </tr> 3907 <tr> 3908 <td headers="ic_prediction_ic" align="center">predictable?</td> 3909 <td headers="ic_prediction_ic">yes (since the ic_name is null)</td> 3910 </tr> 3911 <tr> 3912 <td headers="ic_prediction_ic"></td> 3913 <td headers="ic_prediction_ic"></td> 3914 </tr> 3915 <tr> 3916 <td headers="ic_prediction_ic" align="right">nested class:</td> 3917 <td headers="ic_prediction_ic">non-member, named 3918 <tt>Local</tt></td> 3919 </tr> 3920 <tr> 3921 <td headers="ic_prediction_ic" align="right">mangled name:</td> 3922 <td headers="ic_prediction_ic"> 3923 <tt>java/util/AbstractList$2$Local</tt></td> 3924 </tr> 3925 <tr> 3926 <td headers="ic_prediction_ic" align="right">outer, name:</td> 3927 <td headers="ic_prediction_ic"><em>(none)</em>, <tt>Local</tt></td> 3928 </tr> 3929 <tr> 3930 <td headers="ic_prediction_ic" align="center">predictable?</td> 3931 <td headers="ic_prediction_ic">yes (since the ic_name is 3932 <tt>Local</tt>)</td> 3933 </tr> 3934 <tr> 3935 <td headers="ic_prediction_ic"></td> 3936 <td headers="ic_prediction_ic"></td> 3937 </tr> 3938 <tr> 3939 <td headers="ic_prediction_ic" align="right">nested class:</td> 3940 <td headers="ic_prediction_ic">non-member, named 3941 <tt>Local</tt></td> 3942 </tr> 3943 <tr> 3944 <td headers="ic_prediction_ic" align="right">mangled name:</td> 3945 <td headers="ic_prediction_ic"> 3946 <tt>java/util/AbstractList#2#Local</tt></td> 3947 </tr> 3948 <tr> 3949 <td headers="ic_prediction_ic" align="right">outer, name:</td> 3950 <td headers="ic_prediction_ic"><em>(none)</em>, <tt>Local</tt></td> 3951 </tr> 3952 <tr> 3953 <td headers="ic_prediction_ic" align="center">predictable?</td> 3954 <td headers="ic_prediction_ic">yes (since the ic_name is 3955 <tt>Local</tt>)</td> 3956 </tr> 3957 <tr> 3958 <td headers="ic_prediction_ic"></td> 3959 <td headers="ic_prediction_ic"></td> 3960 </tr> 3961 <tr> 3962 <td headers="ic_prediction_ic" align="right">nested class:</td> 3963 <td headers="ic_prediction_ic">member named <tt>$2$Local</tt> of 3964 <tt>Foo</tt></td> 3965 </tr> 3966 <tr> 3967 <td headers="ic_prediction_ic" align="right">mangled name:</td> 3968 <td headers="ic_prediction_ic"><tt>Foo$$2$Local</tt></td> 3969 </tr> 3970 <tr> 3971 <td headers="ic_prediction_ic" align="right">outer, name:</td> 3972 <td headers="ic_prediction_ic"><em>(none)</em>, <tt>Local</tt></td> 3973 </tr> 3974 <tr> 3975 <td headers="ic_prediction_ic" align="center">predictable?</td> 3976 <td headers="ic_prediction_ic">no (outer name missing, ic_name 3977 mispredicted)</td> 3978 </tr> 3979 <tr> 3980 <td headers="ic_prediction_ic"></td> 3981 <td headers="ic_prediction_ic"></td> 3982 </tr> 3983 <tr> 3984 <td headers="ic_prediction_ic" align="right">nested class:</td> 3985 <td headers="ic_prediction_ic">class named 3986 <tt>Red$Herring</tt></td> 3987 </tr> 3988 <tr> 3989 <td headers="ic_prediction_ic" align="right">mangled name:</td> 3990 <td headers="ic_prediction_ic"><tt>Red$Herring</tt></td> 3991 </tr> 3992 <tr> 3993 <td headers="ic_prediction_ic" align="right">outer, name:</td> 3994 <td headers="ic_prediction_ic"><tt>Red</tt>, <tt>Herring</tt></td> 3995 </tr> 3996 <tr> 3997 <td headers="ic_prediction_ic" align="center">predictable?</td> 3998 <td headers="ic_prediction_ic">no (the predicted ic_name 3999 Herring)</td> 4000 </tr> 4001 <tr> 4002 <td headers="ic_prediction_ic"></td> 4003 <td headers="ic_prediction_ic"></td> 4004 </tr> 4005 <tr> 4006 <td headers="ic_prediction_ic" align="right">nested class:</td> 4007 <td headers="ic_prediction_ic">member named <tt>Q</tt> of 4008 <tt>X$1</tt></td> 4009 </tr> 4010 <tr> 4011 <td headers="ic_prediction_ic" align="right">mangled name:</td> 4012 <td headers="ic_prediction_ic"><tt>X$1$Q</tt></td> 4013 </tr> 4014 <tr> 4015 <td headers="ic_prediction_ic" align="right">outer, name:</td> 4016 <td headers="ic_prediction_ic"><em>(none)</em>, <tt>Q</tt></td> 4017 </tr> 4018 <tr> 4019 <td headers="ic_prediction_ic" align="center">predictable?</td> 4020 <td headers="ic_prediction_ic">no (since <tt>Q</tt> is a member of 4021 <tt>X$1</tt>)</td> 4022 </tr> 4023 <tr> 4024 <td headers="ic_prediction_ic"></td> 4025 <td headers="ic_prediction_ic"></td> 4026 </tr> 4027 <tr> 4028 <td headers="ic_prediction_ic" align="right">nested class:</td> 4029 <td headers="ic_prediction_ic">member named <tt>Z</tt> of 4030 <tt>X$Y</tt></td> 4031 </tr> 4032 <tr> 4033 <td headers="ic_prediction_ic" align="right">mangled name:</td> 4034 <td headers="ic_prediction_ic"><tt>X$Y$Z</tt></td> 4035 </tr> 4036 <tr> 4037 <td headers="ic_prediction_ic" align="right">outer, name:</td> 4038 <td headers="ic_prediction_ic"><tt>X$Y</tt>, <tt>Z</tt></td> 4039 </tr> 4040 <tr> 4041 <td headers="ic_prediction_ic" align="center">predictable?</td> 4042 <td headers="ic_prediction_ic">yes (since X$Y.Z is a member of 4043 X$Y)</td> 4044 </tr> 4045 <tr> 4046 <td headers="ic_prediction_ic"></td> 4047 <td headers="ic_prediction_ic"></td> 4048 </tr> 4049 <tr> 4050 <td headers="ic_prediction_ic" align="right">nested class:</td> 4051 <td headers="ic_prediction_ic">member named <tt>Y$Z</tt> of 4052 <tt>X</tt></td> 4053 </tr> 4054 <tr> 4055 <td headers="ic_prediction_ic" align="right">mangled name:</td> 4056 <td headers="ic_prediction_ic"><tt>X$Y$Z</tt></td> 4057 </tr> 4058 <tr> 4059 <td headers="ic_prediction_ic" align="right">outer, name:</td> 4060 <td headers="ic_prediction_ic"><tt>X$Y</tt>, <tt>Z</tt></td> 4061 </tr> 4062 <tr> 4063 <td headers="ic_prediction_ic" align="center">predictable?</td> 4064 <td headers="ic_prediction_ic">no (outer name and ic_name are 4065 mispredicted)</td> 4066 </tr> 4067 </table> 4068 <p>When a decompressor is processing a nested class name marked 4069 "predictable", it must parse the nested class's bytecode name into 4070 an enclosing class, an optional number, and an optional name. (The 4071 compressor might choose to always specify outer classes and names 4072 explicitly, in which case the decompressor would not be required to 4073 parse the nested class names at all. However, decompressors must 4074 always be prepared to perform this parsing.)</p> 4075 <p>If the compressor did not transmit an entry in <tt>cp_Utf8</tt> 4076 or <tt>cp_Class</tt> for a predicted name or outer class, the 4077 decompressor must create such a constant internally. It will be 4078 referred to as a <tt>cp_Utf8</tt> or <tt>cp_Class</tt> entry, even 4079 though it is not in the constant transmission sequence 4080 <tt>cp_All</tt>. However, if the compressor did transmit a constant 4081 with the same spelling as the predicted name or outer class, the 4082 decompressor must use that constant rather than creating a new one. 4083 The creation of such internal constants within the decompressor is 4084 detectable in an output file because they are inserted in a special 4085 order in the output file's constant pool. (See discussion of the 4086 output ordering rules in the section <a href="#ordering">Ordering of Constant Pools</a>.)</p> 4087 4088 <p>Please see the Appendix section <a href= 4089 "#icn_psc">Representation of Byte Offsets</a> for pseudo-code explaining this concept.</p> 4090 4091 <p>When the decompressor receives the <tt>ic_this_class</tt>, 4092 <tt>ic_flags</tt>, <tt>ic_name</tt>, and <tt>ic_outer_class</tt> 4093 bands, and performs any required name parsing, it creates the set 4094 <tt>ic_All</tt> of four-tuples. This set is the primary source of 4095 <tt>InnerClasses</tt> attributes synthesized for individual class 4096 files by the decompressor.</p> 4097 <a name="tocClaSch" id="tocClaSch"></a> 4098 <h4>5.8. Class Schema</h4> 4099 The purpose of the Pack200 archive is to transmit a set of classes 4100 in a form which a decompressor can later use to reconstruct class 4101 files. As a rule, each separate kind of data stored in class files 4102 is transmitted in a band dedicated to all values of that kind. Here 4103 is the band structure for all class-specific information except 4104 bytecodes: 4105 <pre class="codeblock"> 4106 class_bands: 4107 *class_this :DELTA5 [#class_count] (cp_Class) 4108 *class_super :DELTA5 [#class_count] (cp_Class) 4109 *class_interface_count :DELTA5 [#class_count] 4110 *class_interface :DELTA5 [SUM(*class_interface_count)] (cp_Class) 4111 *class_field_count :DELTA5 [#class_count] 4112 *class_method_count :DELTA5 [#class_count] 4113 4114 *field_descr :DELTA5 [SUM(*class_field_count)] (cp_Descr) 4115 field_attr_bands 4116 4117 *method_descr :MDELTA5 [SUM(*class_method_count)] (cp_Descr) 4118 method_attr_bands 4119 4120 class_attr_bands 4121 code_bands 4122 4123 </pre> 4124 <p>The <tt>class_this</tt>, <tt>class_super</tt>, 4125 <tt>class_flags_lo</tt>, <tt>class_flags_hi</tt> (if present), 4126 <tt>class_interface_count</tt>, <tt>class_field_count</tt>, and 4127 <tt>class_method_count</tt> bands are all of length 4128 <tt>#class_count</tt>, and the corresponding elements of these 4129 bands transmit in turn each class's name and super-class, and the 4130 number of implemented interfaces, declared fields, and declared 4131 methods. (The access modifier bits in each class's flags word are 4132 mixed with attribute indicators, and are transmitted in 4133 <tt>class_flags_lo</tt>, as defined above.)</p> 4134 <p>The <tt>class_interface</tt> band contains runs of class 4135 interface declarations, one run for each element of 4136 <tt>class_interface_count</tt>, and applying to the corresponding 4137 class.</p> 4138 <p>Each element of <tt>class_this</tt>, <tt>class_super</tt>, and 4139 <tt>class_interface</tt> is a reference (in fact, a non-null 4140 reference) to the constant pool <tt>cp_Class</tt>.</p> 4141 <p>In the unique case of <tt>java/lang/Object</tt>, the stored 4142 super-class must be a null reference. Rather than disturbing the 4143 transmission of all other elements of the <tt>class_super</tt> 4144 band, we use the convention that a compressor, when it encounters a 4145 null super-class reference, must transmit in its place a duplicate 4146 of the current class's reference. (Since it is illegal for a class 4147 to inherit from itself, this renumbering of null references is 4148 unambiguous.)</p> 4149 <p>The <tt>field_descr</tt> bands contain one run of elements for 4150 each element of <tt>class_field_count</tt>, and apply to successive 4151 fields in the corresponding class. The <tt>method_descr</tt> bands 4152 contain one run of elements for each element of 4153 <tt>class_method_count</tt>, and apply to successive methods in the 4154 corresponding class.</p> 4155 <p>(Unlike the class file format, field and method descriptors are 4156 stored as single references to a "name-and-type" constant pool, 4157 rather than as pairs of name references and type references.)</p> 4158 <p>The <tt>method_descr</tt> band has a primary encoding which 4159 performs best if the method references are mostly sorted. 4160 Compressors may elect to take advantage of this fact by sorting the 4161 methods in each class. (Note: It is generally acceptable for 4162 compressors to reorder methods for best compression, but fields 4163 must not be reordered, since their order is apparent through 4164 reflection and significant to some facilities, such as 4165 serialization.)</p> 4166 <p>Attribute bands are placed in the positions indicated by the 4167 grammar. They are described below. The attribute bands include 4168 flags bands, which carry both access modifiers and attribute 4169 indicators for the corresponding classes, fields, and methods.</p> 4170 <p>The Pack200 archive ends with bands devoted to method code 4171 blocks and the bytecodes themselves. If a method has a code 4172 attribute, the compressor must mention it in the flags bit (the 6th 4173 LSB) to which it is assigned, or as an overflow attribute (with an 4174 index of 6). The fields of a Code attribute are transmitted in the 4175 bands organized under the <tt>code_bands</tt> nonterminal.</p> 4176 <p>The specification of each Code attribute begins with three key 4177 parameters, which declare the number of stack and local slots, and 4178 the number of handlers. <tt>#Stack</tt> is the number of stack 4179 slots used by the code. <tt>#NALocal</tt> is the number of 4180 non-argument locals used by the code. (The actual number of locals 4181 declared in the class file will be <tt>#NALocal</tt> plus the 4182 number of locals required by method parameters, as determined by 4183 the method's signature.) <tt>#Handler</tt> is the number of 4184 exception handlers.</p> 4185 <a name="code_headers" id="code_headers"></a> 4186 <p>The <tt>code_headers</tt> band contains a series of bytes, each 4187 of which tersely encodes the first three key parameters of a code 4188 attribute: Each of the 255 non-zero byte values encodes a unique 4189 triple of <tt>#NALocal</tt>, <tt>#Stack</tt>, and 4190 <tt>#Handler</tt>. There is (of course) one code header for each 4191 Code attribute transmitted.</p> 4192 <p>The special code header byte zero (0x00) indicates that the code 4193 attribute's three parameters are to be found, instead, in the 4194 <tt>code_max_stack</tt>, <tt>code_max_na_locals</tt>, and 4195 <tt>code_handler_count</tt> bands. If the code header byte is 4196 non-zero, these three bands do not transmit entries for the 4197 corresponding Code attribute.</p> 4198 <p>The <tt>code_flags_lo</tt> band transmits an entry for a 4199 corresponding <tt>Code</tt> attribute if and only if one or both of 4200 the following is true: the Code attribute's code header byte is 4201 zero, or the <tt>have_all_code_flags</tt> bit is set in the 4202 <tt>#archive_options</tt> word. If a <tt>Code</tt> attribute does 4203 not have a transmitted <tt>code_flags_lo</tt> value, its flags word 4204 is taken to be zero, and it has no sub-attributes. The 4205 <tt>code_flags_hi</tt> band transmits a corresponding entry if and 4206 only if the <tt>code_flags_lo</tt> value was transmitted as just 4207 described, and also <tt>#have_code_flags_hi</tt> is set.</p> 4208 <p>Non-zero code header bytes denote code attribute parameters 4209 according to the following scheme:</p> 4210 <table border="1" summary= 4211 "bands that transmit appropriately-typed constant pool references"> 4212 <tr align="center"> 4213 <th id="typed_cp_h">Header Range</th> 4214 <th id="typed_cp_s">#Stack</th> 4215 <th id="typed_cp_n">#NALocal</th> 4216 <th id="typed_cp_h1">#Handler</th> 4217 </tr> 4218 <tr> 4219 <td headers="typed_cp_h">1 <= x <= 144</td> 4220 <td headers="typed_cp_s">(x-1) % 12</td> 4221 <td headers="typed_cp_n">(x-1) / 12</td> 4222 <td headers="typed_cp_h1">0</td> 4223 </tr> 4224 <tr> 4225 <td headers="typed_cp_h">145 <= x <= 208</td> 4226 <td headers="typed_cp_s">(x-145) % 8</td> 4227 <td headers="typed_cp_n">(x-145) / 8</td> 4228 <td headers="typed_cp_h1">1</td> 4229 </tr> 4230 <tr> 4231 <td headers="typed_cp_h">209 <= x <= 255</td> 4232 <td headers="typed_cp_s">(x-209) % 7</td> 4233 <td headers="typed_cp_n">(x-209) / 7</td> 4234 <td headers="typed_cp_h1">2</td> 4235 </tr> 4236 <tr> 4237 <td headers="typed_cp_h">x = 0</td> 4238 <td headers="typed_cp_s"><tt>code_max_stack</tt></td> 4239 <td headers="typed_cp_n"><tt>code_max_na_locals</tt></td> 4240 <td headers="typed_cp_h1"><tt>code_handler_count</tt></td> 4241 </tr> 4242 </table> 4243 This scheme allows a single byte to describe a Code attribute in 4244 about 95% of all cases. (Note: If debugging attributes are not 4245 stripped, the compressor should probably set the 4246 <tt>have_all_code_flags</tt> bit, so that the presence of these 4247 attributes will not force the use of the special zero code header 4248 byte.) 4249 <p>Regardless of whether the exception handler count is encoded in 4250 the one-byte code header, or whether it is an explicit element of 4251 <tt>code_handler_count</tt>, for each code attribute there is a run 4252 of values in <tt>code_handler_start_P</tt>, 4253 <tt>code_handler_end_PO</tt>, <tt>code_handler_catch_PO</tt>, and 4254 <tt>code_handler_class_RCN</tt>, one for each handler, as if those 4255 bands were governed by an attribute layout 4256 <tt>'NV[PHPOHPOHRCNH]'</tt> (there is no band governed by the 4257 <tt>'NV'</tt> layout element itself; it is the handler count).</p> 4258 <p>That is, each triplet of <tt>Handler.start</tt>, 4259 <tt>Handler.end</tt>, and <tt>Handler.catch</tt> values are 4260 transmitted as renumbered (by <em>renumber_bci</em>). Also, 4261 <tt>Handler.end</tt> is transmitted as a difference of its 4262 renumbering with that of <tt>Handler.start</tt> in the same 4263 triplet, and <tt>Handler.catch</tt> is transmitted as a difference 4264 of its renumbering with that of <tt>Handler.end</tt> in the same 4265 triplet. Finally, <tt>code_handler_class_RCN</tt> is transmitted as 4266 an incremented reference into <tt>cp_Class</tt>, or zero if the 4267 handler class reference is null.</p> 4268 <pre class="codeblock"> 4269 code_bands: 4270 *code_headers :BYTE1 [COUNT(Code,...)] 4271 4272 *code_max_stack :UNSIGNED5 [COUNT(0,*code_headers)] 4273 *code_max_na_locals :UNSIGNED5 [COUNT(0,*code_headers)] 4274 4275 *code_handler_count :UNSIGNED5 [COUNT(0,*code_headers)] 4276 *code_handler_start_P :BCI5 [SUM(*code_handler_count)] 4277 *code_handler_end_PO :BRANCH5 [SUM(*code_handler_count)] 4278 *code_handler_catch_PO :BRANCH5 [SUM(*code_handler_count)] 4279 *code_handler_class_RCN :UNSIGNED5 [SUM(*code_handler_count)] (null or cp_Class) 4280 4281 code_attr_bands 4282 4283 </pre> 4284 <a name="tocAttBan" id="tocAttBan"></a> 4285 <h4>5.9. Attribute Bands</h4> 4286 Here, collected in one place, are the bands which transmit 4287 attributes. If the compressor sets bits in the flags word of a 4288 class, field, or method, and those bits are assigned (by the 4289 compressor) to attributes, then the compressor must also retrieve 4290 the stored values governed by each selected attribute layout and 4291 transmit them in the bands governed by that layout. <a name= 4292 "overflow_bits" id="overflow_bits"></a> 4293 <p>If the compressor marks a class (resp. field, method, or code) 4294 as having overflow attributes, it must transmit a corresponding 4295 element in the <tt>class_attr_count</tt> band (resp. 4296 <tt>field_attr_count</tt>, <tt>method_attr_count</tt>, or 4297 <tt>code_attr_count</tt> band). This count, in turn, specifies the 4298 size of a run in <tt>class_attr_indexes</tt> (resp. 4299 <tt>field_attr_indexes</tt>, <tt>method_attr_indexes</tt>, or 4300 <tt>code_attr_indexes</tt>) of indexes of attribute layouts 4301 governing attributes of the class (resp. field, method, or code). 4302 The compressor must transmit a attribute layout definition index 4303 for each overflow attribute.</p> 4304 <p>For each attribute layout selected by a bit in an element of 4305 <tt>class_flags</tt> or by an element of 4306 <tt>class_attr_indexes</tt>, the compressor must retrieve data 4307 governed by the layout elements from the class attribute and 4308 transmit elements encoding this data in the bands governed by the 4309 layout. Similar conditions apply for field, method, and code 4310 attributes.</p> 4311 <p>For each attribute layout that transmits data and contains 4312 backward calls, the compressor must transmit the number of times 4313 each backward callable will be the subject of a backward call as 4314 the decompressor works its way through attribute layouts. These 4315 call counts are transmitted in the <tt>class_attr_calls</tt>, 4316 <tt>field_attr_calls</tt>, <tt>method_attr_calls</tt>, and 4317 <tt>code_attr_calls</tt> bands, according to the context type of 4318 the layouts they apply to. The call counts are transmitted, one per 4319 backward callable, in the definition order of the callables. (See the section 4320 <a href="#def_order">Attribute Layout Definitions</a>.) Call counts are only transmitted 4321 for backward callables which occur within layouts that are used at 4322 least once. Call counts do <em>not</em> count entries to any 4323 callable because of a forward call, nor do they count the initial 4324 call to a callable which initiates attribute processing. A call 4325 count might be zero if a backward callable occurs in a layout that 4326 is used, but which does not happen to reach the backward callable. 4327 These call counts are needed to break a circularity inherent in the 4328 sizing of bands for mutually-recursive layouts. They provide the 4329 minimum information necessary for the decompressor to locate all 4330 the bands in the archive, prior to distributing the band values to 4331 the various output classes. For this reason, the call counts are 4332 supplied one per layout, summed over all attribute occurrences of 4333 that each layout.</p> 4334 <p>The decompressor is responsible for processing any explicit 4335 attribute layout definitions transmitted by the compressor. It must 4336 prepare to receive the additional bands governed by those layouts. 4337 When it reads layout definition indexes, it must prepare to read in 4338 the correct number of values transmitted in each of those 4339 additional bands.</p> 4340 <p>The grammar of bands defined in this specification includes 4341 bands governed by all predefined attribute layouts. For clarity, 4342 some band names mention a part of the layout element that created 4343 them. Note that the Deprecated attributes have no bands, because 4344 their layouts are empty.</p> 4345 <p>Attributes named "Synthetic", although part of the standard 4346 class file format in earlier versions of Java, are not directly 4347 supported in this specification, because that attribute has been 4348 replaced by a new flag bit (ACC_SYNTHETIC, 0x1000) in more recent 4349 versions of Java. However, compressors are encouraged to process 4350 Synthetic attributes, and any other zero-length attributes not 4351 predefined here, by assigning them unused flag bits, and emitting 4352 explicit zero-length layout definitions for decompressors to 4353 follow.</p> 4354 <p>If the compressor elects to define new layouts, the bands 4355 governed by those layouts are added immediately after the bands for 4356 the predefined layouts. (The order and structure of the predefined 4357 attribute bands reflects the predefined layout definitions in a 4358 regular way, as if the compressor had in fact defined them 4359 explicitly.)</p> 4360 <pre class="codeblock"> 4361 4362 class_attr_bands: 4363 *class_flags_hi :UNSIGNED5 [#class_count*#have_class_flags_hi] 4364 *class_flags_lo :UNSIGNED5 [#class_count] 4365 *class_attr_count :UNSIGNED5 [COUNT(1<<16,...)] 4366 *class_attr_indexes :UNSIGNED5 [SUM(*class_attr_count)] 4367 *class_attr_calls :UNSIGNED5 [...] 4368 *class_SourceFile_RUN :UNSIGNED5 [COUNT(SourceFile,...)] (null or cp_Utf8) 4369 *class_EnclosingMethod_RC :UNSIGNED5 [COUNT(EnclosingMethod,...)] (cp_Class) 4370 *class_EnclosingMethod_RDN :UNSIGNED5 [COUNT(EnclosingMethod,...)] (null or cp_Descr) 4371 *class_Signature_RS :UNSIGNED5 [COUNT(Signature,..)] (cp_Signature) 4372 class_metadata_bands 4373 ic_local_bands 4374 *class_file_version_minor_H :UNSIGNED5 [COUNT(version,...)] 4375 *class_file_version_major_H :UNSIGNED5 [COUNT(version,...)] 4376 {class_attr_element_bands...} 4377 4378 field_attr_bands: 4379 *field_flags_hi :UNSIGNED5 [SUM(*class_field_count)*#have_field_flags_hi] 4380 *field_flags_lo :UNSIGNED5 [SUM(*class_field_count)] 4381 *field_attr_count :UNSIGNED5 [COUNT(1<<16,...)] 4382 *field_attr_indexes :UNSIGNED5 [SUM(*field_attr_count)] 4383 *field_attr_calls :UNSIGNED5 [...] 4384 *field_ConstantValue_KQ :UNSIGNED5 [COUNT(ConstantValue,...)] (cp_Int, etc.; see note) 4385 *field_Signature_RS :UNSIGNED5 [COUNT(Signature,...)] (cp_Signature) 4386 field_metadata_bands 4387 4388 method_attr_bands: 4389 *method_flags_hi :UNSIGNED5 [SUM(*class_method_count)*#have_method_flags_hi] 4390 *method_flags_lo :UNSIGNED5 [SUM(*class_method_count)] 4391 *method_attr_count :UNSIGNED5 [COUNT(1<<16,...)] 4392 *method_attr_indexes :UNSIGNED5 [SUM(*method_attr_count)] 4393 *method_attr_calls :UNSIGNED5 [...] 4394 *method_Exceptions_N :UNSIGNED5 [COUNT(Exceptions,...)] 4395 *method_Exceptions_RC :UNSIGNED5 [SUM(*method_Exceptions_N)] (cp_Class) 4396 *method_Signature_RS :UNSIGNED5 [COUNT(Signature,...)] (cp_Signature) 4397 method_metadata_bands 4398 *method_MethodParameters_NB :BYTE1 [...] 4399 *method_MethodParameters_name_RUN :UNSIGNED5 [...] (null or cp_Utf8) 4400 *method_MethodParameters_flag_FH :UNSIGNED5 [...] (flag) 4401 {method_attr_element_bands...} 4402 4403 code_attr_bands: 4404 *code_flags_hi :UNSIGNED5 [...*#have_code_flags_hi] 4405 *code_flags_lo :UNSIGNED5 [...] 4406 *code_attr_count :UNSIGNED5 [COUNT(1<<16,...)] 4407 *code_attr_indexes :UNSIGNED5 [SUM(*code_attr_count)] 4408 *code_attr_calls :UNSIGNED5 [...] 4409 *code_StackMapTable_N :UNSIGNED5 [COUNT(StackMapTable,...)] 4410 *code_StackMapTable_frame_T :BYTE1 [SUM(*code_StackMapTable_N)] 4411 *code_StackMapTable_local_N :UNSIGNED5 [COUNT(255,*code_StackMapTable_frame_T)] 4412 *code_StackMapTable_stack_N :UNSIGNED5 [COUNT(255,*code_StackMapTable_frame_T)] 4413 *code_StackMapTable_offset :UNSIGNED5 [...] 4414 *code_StackMapTable_T :BYTE1 [...] 4415 *code_StackMapTable_RC :UNSIGNED5 [COUNT(7,*code_StackMapTable_T)] 4416 *code_StackMapTable_P :BCI5 [COUNT(8,*code_StackMapTable_T)] 4417 *code_LineNumberTable_N :UNSIGNED5 [...] 4418 *code_LineNumberTable_bci_P :BCI5 [...] 4419 *code_LineNumberTable_line :UNSIGNED5 [...] 4420 *code_LocalVariableTable_N :UNSIGNED5 [...] 4421 *code_LocalVariableTable_bci_P :BCI5 [...] 4422 *code_LocalVariableTable_span_O :BRANCH5 [...] 4423 *code_LocalVariableTable_name_RU :UNSIGNED5 [...] (cp_Utf8) 4424 *code_LocalVariableTable_type_RS :UNSIGNED5 [...] (cp_Signature) 4425 *code_LocalVariableTable_slot :UNSIGNED5 [...] 4426 *code_LocalVariableTypeTable_N :UNSIGNED5 [...] 4427 *code_LocalVariableTypeTable_bci_P :BCI5 [...] 4428 *code_LocalVariableTypeTable_span_O :BRANCH5 [...] 4429 *code_LocalVariableTypeTable_name_RU :UNSIGNED5 [...] (cp_Utf8) 4430 *code_LocalVariableTypeTable_type_RS :UNSIGNED5 [...] (cp_Signature) 4431 *code_LocalVariableTypeTable_slot :UNSIGNED5 [...] 4432 {code_attr_element_bands...} 4433 4434 </pre> 4435 <a name="special_version_number" id="special_version_number"></a> 4436 <p>A class possesses a "class-file version" pseudo-attribute if its 4437 class file's minor or major version differs from the 4438 <tt>#default_class_minver</tt> or <tt>#default_class_majver</tt>, 4439 respectively. This pseudo-attribute is a pair of 16-bit integers 4440 giving the major and minor version numbers of the class's file. 4441 These integers are stored in the header of the class's file, rather 4442 than in an attribute record. As is the convention with classfiles, 4443 the minor version number comes first. Thus minor version numbers 4444 are transmitted in the band <tt>class_file_version_minor_H</tt>, 4445 and major version numbers in <tt>class_file_version_major_H</tt>. 4446 Decompressors are not required to process archives with greater 4447 minor or major version numbers than those of the specification they 4448 were engineered to process. Decompressors are required to process 4449 archives with the same major and smaller or equal minor version 4450 numbers.</p> 4451 <a name="ic_local_bands" id="ic_local_bands"></a> 4452 <h5>Local InnerClasses Attributes</h5> 4453 A transmitted class may possess a local <tt>InnerClasses</tt> 4454 attribute, which is taken to be an <em>adjustment</em> to that 4455 class file's eventually written <tt>InnerClasses</tt> attribute. 4456 Specifically, the local <tt>InnerClasses</tt> attribute specifes a 4457 set of four-tuples which must be combined with a corresponding 4458 relevant subset drawn from <tt>ic_All</tt>. The algorithm for doing 4459 this is described in the section <a href="#ic_subset_selection">Ordering of Constant Pools</a>, 4460 but it amounts to starting with the subset of four-tuples from 4461 <tt>ic_All</tt> which pertain to CONSTANT_Class entries of the 4462 output constant pool (barring CONSTANT_Class entries required only 4463 by the <tt>InnerClasses</tt> attribute itself), and then forming 4464 the set symmetric difference between that relevant set and the 4465 local <tt>InnerClasses</tt> attribute. 4466 <p>The four-tuples of all local <tt>InnerClasses</tt> attributes 4467 are transmitted in five bands:</p> 4468 <pre class="codeblock"> 4469 ic_local_bands: 4470 *class_InnerClasses_N :UNSIGNED5 [COUNT(InnerClasses,...)] 4471 *class_InnerClasses_RC :UNSIGNED5 [SUM(*class_InnerClasses_N)] (cp_Class) 4472 *class_InnerClasses_F :UNSIGNED5 [SUM(*class_InnerClasses_N)] 4473 *class_InnerClasses_outer_RCN :UNSIGNED5 [COUNT(!=0,*class_InnerClasses_F)] (null or cp_Class) 4474 *class_InnerClasses_name_RUN :UNSIGNED5 [COUNT(!=0,*class_InnerClasses_F)] (null or cp_Utf8) 4475 4476 </pre> 4477 <p>Each four-tuple <tt><C,F,C2,N></tt> transmitted in these 4478 attribute bands is called a <em>local IC tuple</em>. (Note that the 4479 class file format stores the elements of these four-tuples in a 4480 different order, <tt>(C,C2,N,F)</tt>.) For a given class file X, 4481 the sequence of local IC tuples is called <tt>ic_Local(X)</tt>.</p> 4482 <p>For each local IC tuple, the compressor transmits, at minimum, a 4483 <tt>C</tt> value and an <tt>F</tt> value. If a transmitted flags 4484 value <tt>F</tt> is not zero, there are also corresponding 4485 transmitted constant pool references <tt>C2</tt> and <tt>N</tt>. As 4486 a whole, the transmitted local tuple may or may not be equivalent 4487 to a global tuple from <tt>ic_All</tt>.</p> 4488 <p>As an abbreviation, the compressor may transmit only a 4489 <tt>C</tt> and a flags value of zero, if the local IC tuple to be 4490 transmitted is equivalent to a member of <tt>ic_All</tt>, and no 4491 other member of <tt>ic_All</tt> defines the same class <tt>C</tt>. 4492 In this case the decompressor must behave exactly as if all four 4493 tuple components had been explicitly transmitted.</p> 4494 <p>(If all four components of a local tuple are transmitted, and 4495 the flags value to be transmitted is in fact zero, the value 4496 <tt>0x00010000</tt> must be transmitted instead of zero for the 4497 flags.)</p> 4498 <p>Frequently, the compressor will not need to transmit any local 4499 IC tuples at all, since the set of four-tuples to be stored in the 4500 class's <tt>InnerClasses</tt> attribute will be exactly 4501 <tt>ic_Relevant(X)</tt>, with no adjustment required. If extraneous 4502 four-tuples (beyond those required by a minimized constant pool) 4503 are found in the input class file, then some local IC tuples will 4504 be needed (with zero flags), to provide local "roots" for the extra 4505 <tt>InnerClasses</tt> entries. This can occur if a compiler 4506 requires an <tt>InnerClasses</tt> entry for a class mentioned only 4507 in a signature. Compressors are required to predict which classes 4508 require such extra local roots, and transmit only the unexpected 4509 four-tuples.</p> 4510 <a name="tocMetTra" id="tocMetTra"></a> 4511 <h5>5.9.1. Metadata Transmission</h5> 4512 There are nine groups of bands governed by the metadata layouts. 4513 They are summarized here. 4514 <pre class="codeblock"> 4515 class_metadata_bands: 4516 class_RVA_bands 4517 class_RIA_bands 4518 4519 field_metadata_bands: 4520 field_RVA_bands 4521 field_RIA_bands 4522 4523 method_metadata_bands: 4524 method_RVA_bands 4525 method_RIA_bands 4526 method_RVPA_bands 4527 method_RIPA_bands 4528 method_AD_bands 4529 4530 class_RVA_bands: 4531 *class_RVA_anno_N :UNSIGNED5 [...] 4532 *class_RVA_type_RS :UNSIGNED5 [...] (cp_Signature) 4533 *class_RVA_pair_N :UNSIGNED5 [...] 4534 *class_RVA_name_RU :UNSIGNED5 [...] (cp_Utf8) 4535 *class_RVA_T :BYTE1 [...] 4536 *class_RVA_caseI_KI :UNSIGNED5 [...] (cp_Int) 4537 *class_RVA_caseD_KD :UNSIGNED5 [...] (cp_Double) 4538 *class_RVA_caseF_KF :UNSIGNED5 [...] (cp_Float) 4539 *class_RVA_caseJ_KJ :UNSIGNED5 [...] (cp_Long) 4540 *class_RVA_casec_RS :UNSIGNED5 [...] (cp_Signature) 4541 *class_RVA_caseet_RS :UNSIGNED5 [...] (cp_Signature) 4542 *class_RVA_caseec_RU :UNSIGNED5 [...] (cp_Utf8) 4543 *class_RVA_cases_RU :UNSIGNED5 [...] (cp_Utf8) 4544 *class_RVA_casearray_N :UNSIGNED5 [...] 4545 *class_RVA_nesttype_RS :UNSIGNED5 [...] (cp_Signature) 4546 *class_RVA_nestpair_N :UNSIGNED5 [...] 4547 *class_RVA_nestname_RU :UNSIGNED5 [...] (cp_Utf8) 4548 4549 class_RIA_bands: 4550 *class_RIA_anno_N :UNSIGNED5 [...] 4551 (analogous to class_RVA_bands) 4552 4553 field_RVA_bands: 4554 *field_RVA_anno_N :UNSIGNED5 [...] 4555 (analogous to class_RVA_bands) 4556 4557 field_RIA_bands: 4558 *field_RIA_anno_N :UNSIGNED5 [...] 4559 (analogous to field_RVA_bands) 4560 4561 method_RVA_bands: 4562 *method_RVA_anno_N :UNSIGNED5 [...] 4563 (analogous to class_RVA_bands) 4564 4565 method_RIA_bands: 4566 *method_RIA_anno_N :UNSIGNED5 [...] 4567 (analogous to method_RIA_bands) 4568 4569 method_RVPA_bands: 4570 *method_RVPA_param_NB :BYTE1 [...] 4571 *method_RVPA_anno_N :UNSIGNED5 [...] 4572 (analogous to method_RVA_bands) 4573 4574 method_RIPA_bands: 4575 *method_RIPA_param_NB :BYTE1 [...] 4576 *method_RIPA_anno_N :UNSIGNED5 [...] 4577 (analogous to method_RVPA_bands) 4578 4579 method_AD_bands 4580 *method_AD_T :BYTE1 [...] 4581 *method_AD_caseI_KI :UNSIGNED5 [...] (cp_Int) 4582 *method_AD_caseD_KD :UNSIGNED5 [...] (cp_Double) 4583 *method_AD_caseF_KF :UNSIGNED5 [...] (cp_Float) 4584 *method_AD_caseJ_KJ :UNSIGNED5 [...] (cp_Long) 4585 *method_AD_casec_RS :UNSIGNED5 [...] (cp_Signature) 4586 *method_AD_caseet_RS :UNSIGNED5 [...] (cp_Signature) 4587 *method_AD_caseec_RU :UNSIGNED5 [...] (cp_Utf8) 4588 *method_AD_cases_RU :UNSIGNED5 [...] (cp_Utf8) 4589 *method_AD_casearray_N :UNSIGNED5 [...] 4590 *method_AD_nesttype_RS :UNSIGNED5 [...] (cp_Signature) 4591 *method_AD_nestpair_N :UNSIGNED5 [...] 4592 *method_AD_nestname_RU :UNSIGNED5 [...] (cp_Utf8) 4593 4594 </pre> 4595 <p>As an aid to understanding the metadata layout, here is a brief 4596 description of each of the method metadata bands, as used by 4597 classfiles which comply with JSR 175. The class and field metadata 4598 bands function in a similar way.</p> 4599 <p>Note that JSR 175 does not allow embedded references to 4600 CONSTANT_Class entries, even where a reference to a class is 4601 required. Instead, JSR 175 requires that references to classes be 4602 encoded as field signatures. (Their names are bracketed by 'L' and 4603 ';'.) The Pack200 archive transmits all such values as references 4604 into <tt>cp_Signature</tt>, not <tt>cp_Class</tt>.</p> 4605 <p>For each use of a parameter annotation attribute, the 4606 <tt>method_RVPA_param_NB</tt> band or <tt>method_RIPA_param_NB</tt> 4607 band (for invisible annotations) transmits an unsigned byte 4608 indicating the parameter count. For each use of a non-parameter 4609 annotation attribute, the <tt>method_RVA_anno_N</tt> band or 4610 <tt>method_RIA_anno_N</tt> band (for invisible annotations) 4611 transmits an annotation count. Likewise, for each annotated 4612 parameter, the <tt>method_RVPA_anno_N</tt> band or 4613 <tt>method_RIPA_anno_N</tt> band (for invisible annotations) 4614 transmits an annotation count.</p> 4615 <p>For each visible non-parameter annotation, the 4616 <tt>method_RVA_type_RS</tt> band transmits an annotation's type, 4617 and the <tt>method_RVA_pair_N</tt> band transmits the number of 4618 that annotation's member-value pairs. Analogous values for 4619 invisible annotations and parameter annotations are transmitted in 4620 the bands <tt>method_RIA_type_RS</tt>, <tt>method_RIA_pair_N</tt>, 4621 <tt>method_RVPA_type_RS</tt>, <tt>method_RVPA_pair_N</tt>, 4622 <tt>method_RIPA_type_RS</tt>, and <tt>method_RIPA_pair_N</tt>. For 4623 each member-value pair transmitted as a direct part of a visible 4624 non-parameter annotation, the <tt>method_RVA_name_RU</tt> band 4625 transmits the member name. Analogous values for invisible 4626 annotations and parameter annotations are transmitted in the bands 4627 <tt>method_RIA_name_RU</tt>, <tt>method_RVPA_name_RU</tt>, and 4628 <tt>method_RIPA_name_RU</tt>.</p> 4629 <p>For each value transmitted with a visible non-parameter 4630 annotation, whether directly, or indirectly via a nested value or 4631 annotation, the <tt>method_RVA_T</tt> band transmits a byte which 4632 selects the format of the annotation value, and analogous values 4633 are transmitted in the bands <tt>method_RIA_T</tt>, 4634 <tt>method_RVPA_T</tt>, <tt>method_RIPA_T</tt>, and (for annotation 4635 defaults) <tt>method_AD_T</tt>, Direct uses of these value tag 4636 bands are counted by summing the values of the corresponding 4637 preceding pair-count band (<tt>method_RVA_pair_N</tt>, etc.). This 4638 count also includes the sum of the corresponding following nested 4639 pair-count band (<tt>method_RVA_nestpair_N</tt>, etc.) and nested 4640 array length bands (<tt>method_RVA_casearray_N</tt>, etc.).</p> 4641 <p>Since those latter sums come from backward calls in the 4642 attribute layout, they cannot be directly computed by the 4643 decompressor, but their sum is reported by the compressor as an 4644 element of <tt>method_attr_calls</tt>. (Note that the last callable 4645 in each metadata layout is the target of two backward calls from 4646 inside itself.) That band contains these backward call counts for 4647 <tt>method_RVA_T</tt>, <tt>method_RIA_T</tt> 4648 <tt>method_RVPA_T</tt>, <tt>method_RIPA_T</tt> 4649 <tt>method_AD_T</tt>, in that order. If there are no occurrences of 4650 a method metadata attribute, then the corresponding backward call 4651 is omitted. (Thus, there are up to five backward call counts 4652 transmitted for method metadata.) If there are compressor-defined 4653 recursive layouts used in the archive, their backward call counts 4654 follow the counts for metadata in <tt>method_attr_calls</tt>.</p> 4655 <p>For each value tag of 'B', 'C', 'I', 'S', or 'Z', there is a 4656 corresponding element transmitted in <tt>method_RVA_caseI_KI</tt> 4657 which supplies the value as a <tt>cp_Int</tt> reference. Analogous 4658 integer references within invisible and parameter annotations and 4659 annotation defaults are transmitted in the bands 4660 <tt>method_RIA_caseI_KI</tt>, <tt>method_RVPA_caseI_KI</tt>, 4661 <tt>method_RIPA_caseI_KI</tt>, and <tt>method_AD_caseI_KI</tt>. For 4662 each value tag of 'e', the bands <tt>method_RVA_caseet_RS</tt> and 4663 <tt>method_RVA_caseec_RU</tt> transmit the signature of the class 4664 and name of the member of an enumeration constant, as references 4665 into <tt>cp_Signature</tt> and <tt>cp_Utf8</tt>. For each value tag 4666 of '[', the band <tt>method_RVA_casearray_N</tt> transmits the 4667 length of a nested value array. For each value tag of '@', the 4668 bands <tt>method_RVA_nesttype_RS</tt> and 4669 <tt>method_RVA_nestpair_N</tt> transmit the class signature of a 4670 nested annotation and the number of its pairs. For each pair in 4671 such a nested annotation, the band <tt>method_RVA_nestname_RU</tt> 4672 transmits the name of the pair.</p> 4673 <p>The bands in the following table transmit appropriately-typed 4674 constant pool references for each occurrence of specific tag 4675 characters.</p> 4676 <table border="1" summary="details about escape code"> 4677 <tr align="center"> 4678 <th id="escape_code_details_t">Tag(s)</th> 4679 <th id="escape_code_details_b">Band</th> 4680 <th id="escape_code_details_r">Reference</th> 4681 </tr> 4682 <tr> 4683 <td headers="escape_code_details_t"> 4684 <tt>'B','C','I','S','Z'</tt></td> 4685 <td headers="escape_code_details_b"> 4686 <tt>method_RVA_caseI_KI</tt></td> 4687 <td headers="escape_code_details_r">cp_Int</td> 4688 </tr> 4689 <tr> 4690 <td headers="escape_code_details_t"><tt>'D'</tt></td> 4691 <td headers="escape_code_details_b"> 4692 <tt>method_RVA_caseD_KD</tt></td> 4693 <td headers="escape_code_details_r">cp_Double</td> 4694 </tr> 4695 <tr> 4696 <td headers="escape_code_details_t"><tt>'F'</tt></td> 4697 <td headers="escape_code_details_b"> 4698 <tt>method_RVA_caseF_KF</tt></td> 4699 <td headers="escape_code_details_r">cp_Float</td> 4700 </tr> 4701 <tr> 4702 <td headers="escape_code_details_t"><tt>'J'</tt></td> 4703 <td headers="escape_code_details_b"> 4704 <tt>method_RVA_caseJ_KJ</tt></td> 4705 <td headers="escape_code_details_r">cp_Long</td> 4706 </tr> 4707 <tr> 4708 <td headers="escape_code_details_t"><tt>'c'</tt></td> 4709 <td headers="escape_code_details_b"> 4710 <tt>method_RVA_casec_RS</tt></td> 4711 <td headers="escape_code_details_r">cp_Signature</td> 4712 </tr> 4713 <tr> 4714 <td headers="escape_code_details_t"><tt>'e'</tt></td> 4715 <td headers="escape_code_details_b"> 4716 <tt>method_RVA_caseet_RS</tt><br /> 4717 <tt>method_RVA_caseec_RU</tt></td> 4718 <td headers="escape_code_details_r"><tt>cp_Signature</tt><br /> 4719 <tt>cp_Utf8</tt></td> 4720 </tr> 4721 <tr> 4722 <td headers="escape_code_details_t"><tt>'s'</tt></td> 4723 <td headers="escape_code_details_b"> 4724 <tt>method_RVA_cases_RU</tt></td> 4725 <td headers="escape_code_details_r">cp_Utf8</td> 4726 </tr> 4727 </table> 4728 <p>Analogous groups of bands transmit values within the other four 4729 method annotation types, and within the visible and invisible 4730 annotations of classes and fields.</p> 4731 <a name="tocBytIns" id="tocBytIns"></a> 4732 <h4>5.10. Bytecode Instructions</h4> 4733 The last part of the Pack200 archive is a series of bands 4734 transmitting the bytecodes themselves. The bytecodes of each method 4735 code are parsed into instructions and operands transmitted in their 4736 own bands. Each method code corresponds to a run of bytecodes which 4737 ends with the distinguished code value 0xFF (255), which serves as 4738 an end marker. (Note that it is unusual for band data to be 4739 delimited by an end marker: Usually it is sized by a count in a 4740 previous band.) 4741 <p>Here are the bands which transmit bytecode instructions:</p> 4742 <pre class="codeblock"> 4743 bc_bands: 4744 *bc_codes :BYTE1 [...] 4745 *bc_case_count :UNSIGNED5 [COUNT(switch,*bc_codes)] 4746 *bc_case_value :DELTA5 [...] 4747 *bc_byte :BYTE1 [...] 4748 *bc_short :DELTA5 [...] 4749 *bc_local :UNSIGNED5 [...] 4750 *bc_label :BRANCH5 [...] 4751 *bc_intref :DELTA5 [...] (cp_Int) 4752 *bc_floatref :DELTA5 [...] (cp_Float) 4753 *bc_longref :DELTA5 [...] (cp_Long) 4754 *bc_doubleref :DELTA5 [...] (cp_Double) 4755 *bc_stringref :DELTA5 [...] (cp_String) 4756 *bc_loadablevalueref :DELTA5 [...] (cp_LoadableValue) 4757 *bc_classref :UNSIGNED5 [...] (current class or cp_Class) 4758 *bc_fieldref :DELTA5 [...] (cp_Field) 4759 *bc_methodref :UNSIGNED5 [...] (cp_Method) 4760 *bc_imethodref :DELTA5 [...] (cp_Imethod) 4761 *bc_indyref :DELTA5 [...] (cp_InvokeDynamic) 4762 *bc_thisfield :UNSIGNED5 [...] (cp_Field, only for current class) 4763 *bc_superfield :UNSIGNED5 [...] (cp_Field, only for current super) 4764 *bc_thismethod :UNSIGNED5 [...] (cp_Method, only for current class) 4765 *bc_supermethod :UNSIGNED5 [...] (cp_Method, only for current super) 4766 *bc_initref :UNSIGNED5 [...] (cp_Field, only for most recent new) 4767 *bc_escref :UNSIGNED5 [COUNT(ref_escape,*bc_codes)] (cp_All) 4768 *bc_escrefsize :UNSIGNED5 [...] 4769 *bc_escsize :UNSIGNED5 [...] 4770 *bc_escbyte :BYTE1 [...] 4771 4772 </pre> 4773 <p>In order to transmit bytecode instructions more efficiently, 4774 some instructions may be rewritten into a transmission form. The 4775 ldc, ldc_w, and ldc2_w bytecodes must be rewritten by the 4776 compressor into strongly-typed operations; see below. Some 4777 getstatic, putstatic, getfield, putfield, invokevirtual, 4778 invokespecial, and invokestatic bytecodes <em>may</em> (at the 4779 compressor's option) be rewritten into more specialized and compact 4780 forms which, because they are context sensitive, select their 4781 operands from a smaller set of possibilities.</p> 4782 <p>In all cases, the first byte of each instruction (perhaps 4783 rewritten) is determined by a byte transmitted in 4784 <tt>bc_codes</tt>. All operand bytes are decoded into operands and 4785 transmitted in separate bands according to the type of operand 4786 encoded. The padding bytes of switch instructions and the last two 4787 bytes of invokeinterface instructions are discarded, because they 4788 can be reconstructed by the decompressor.</p> 4789 <p>A "wide" prefix bytecode is transmitted in <tt>bc_codes</tt>. 4790 The instruction following the prefix is decoded in its wide format, 4791 but (except in the case of iinc) it is transmitted in the same way, 4792 and using the same bands, as the normal (non-wide) format. The wide 4793 format of the iinc instruction uses <tt>bc_short</tt> instead of 4794 <tt>bc_byte</tt> to transmit its second operand.</p> 4795 <p>Every branch instruction transmits its target (or targets, in 4796 the case of the switches) in the <tt>bc_label</tt> band, encoded as 4797 the difference between the renumbered BCI of the branch target and 4798 the renumbered BCI of the branch itself. (The renumbering, as 4799 described in the section <a href="#bci_renumbering">Attribute Layout Definition</a>, numbers the first 4800 instruction as zero, the second as one, and so forth.) Differences 4801 between renumbered BCIs are very compact; the primary encoding of 4802 BRANCH5 also takes advantage of the fact that most such differences 4803 are positive, because most branches are forward branches.</p> 4804 <p>The <tt>bc_classref</tt> band carries incremented indexes into 4805 the <tt>cp_Class</tt> constant pool. The incrementing (by unity) 4806 reserves the code zero, which always refers to the current class. 4807 (This provides a a compact form for the most common class 4808 reference, which is a self-reference.)</p> 4809 <p>The <tt>bc_byte</tt> and <tt>bc_short</tt> bands carry 4810 fixed-sized operands. These operands are not transmitted as general 4811 32-bit integers because their instructions, as originally defined, 4812 already serve as specially compressed transmission formats. Integer 4813 values of these bands are treated as unsigned, even when they are 4814 semantically signed as operands. The <tt>bc_byte</tt> band is used 4815 for the last operands of multianewarray and non-wide iinc 4816 instructions, and for the operands of bipush and newarray 4817 instructions. The <tt>bc_short</tt> band is used for the last 4818 operands of wide iinc instructions, and for the operands of sipush 4819 instructions.</p> 4820 <p>The bands <tt>bc_intref</tt>, <tt>bc_floatref</tt>, 4821 <tt>bc_longref</tt>, <tt>bc_doubleref</tt>, <tt>bc_stringref</tt>, 4822 <tt>bc_fieldref</tt>, <tt>bc_methodref</tt>, and 4823 <tt>bc_imethodref</tt> transmit ordinary indexes into the constant 4824 pools <tt>cp_Int</tt>, <tt>cp_Float</tt>, <tt>cp_Long</tt>, 4825 <tt>cp_Double</tt>, <tt>cp_String</tt>, <tt>cp_Field</tt>, 4826 <tt>cp_Method</tt>, and <tt>cp_Imethod</tt>, respectively.</p> 4827 <p>The band <tt>bc_indyref</tt> transmits indexes into 4828 <tt>cp_InvokeDynamic</tt>, for <tt>invokedynamic</tt> 4829 instructions.</p> 4830 <p>The band <tt>bc_loadablevalueref</tt> transmits indexes into the constant 4831 pool group <tt>cp_LoadableValue</tt>, such that zero refers to the 4832 first CONSTANT_Integer constant, and so on. It is transmitted 4833 immediately after <tt>bc_stringref</tt>. (Typically, this band is 4834 used for <tt>cp_MethodHandle</tt> constants.)</p> 4835 <p>(The <tt>invokedynamic</tt> instructions may only appear when 4836 <tt>#archive_majver</tt> is 170 or higher. They and their related 4837 constant pool types were introduced in recent revisions of the 4838 classfile format.)</p> 4839 <p>For every lookupswitch or tableswitch instruction, the number of 4840 cases is transmitted in <tt>bc_case_count</tt>, and the default 4841 label is transmitted in <tt>bc_label</tt>. Each case value and case 4842 target of a lookupswitch is transmitted in <tt>bc_case_value</tt> 4843 and <tt>bc_label</tt>, respectively. The initial case value of a 4844 tableswitch is transmitted in <tt>bc_case_value</tt>, and each of 4845 its case targets is transmitted in <tt>bc_label</tt>.</p> 4846 <p>If the first byte of an instruction has a code in the range 4847 [202..255], or if an instruction's operands cannot be parsed 4848 according to the requirements of this specification, it is a 4849 non-standard instruction. Every byte of a non-standard instruction 4850 must be transmitted in a special envelope in order to warn the 4851 decompressor to accept it literally. The envelope consists of a 4852 series of "byte_escape" and "ref_escape" opcodes in the 4853 <tt>bc_code</tt> band, corresponding sizes in <tt>bc_escsize</tt> 4854 and <tt>bc_escrefsize</tt>, bytes in <tt>bc_escbyte</tt>, and 4855 constant pool references in <tt>bc_escref</tt>. Every constant pool 4856 reference in a non-standard instruction must be escaped and 4857 transmitted in the <tt>bc_escref</tt> band. Each ref_escape wraps 4858 one such constant pool reference, of size up to four bytes. The 4859 transmitted reference is an index into <tt>cp_All</tt>, such that 4860 zero refers to the first CONSTANT_Utf8 constant, and so on.</p> 4861 <table border="1" summary="escape codes"> 4862 <tr align="center"> 4863 <th id="escape_code_e">Escape<br /> 4864 Opcode</th> 4865 <th id="escape_code_so">Size<br /> 4866 Operand</th> 4867 <th id="escape_code_os">Operand<br /> 4868 Size</th> 4869 <th id="escape_code_sb">Size<br /> 4870 Band</th> 4871 <th id="escape_code_d">Data<br /> 4872 Band</th> 4873 <th id="escape_code_ov">Opcode<br /> 4874 Value</th> 4875 </tr> 4876 <tr> 4877 <td headers="escape_code_e">byte_escape</td> 4878 <td headers="escape_code_so">N<=255</td> 4879 <td headers="escape_code_os">N bytes</td> 4880 <td headers="escape_code_sb"><tt>bc_escsize</tt></td> 4881 <td headers="escape_code_d"><tt>bc_escbyte</tt></td> 4882 <td headers="escape_code_ov">254</td> 4883 </tr> 4884 <tr> 4885 <td headers="escape_code_e">ref_escape</td> 4886 <td headers="escape_code_so">N<=2</td> 4887 <td headers="escape_code_os">N bytes</td> 4888 <td headers="escape_code_sb"><tt>bc_escrefsize</tt></td> 4889 <td headers="escape_code_d"><tt>bc_escref</tt></td> 4890 <td headers="escape_code_ov">253</td> 4891 </tr> 4892 </table> 4893 <p>There is no need for special transmission of any other operand 4894 type within non-standard instructions, because the Pack200 format 4895 exactly preserves all instruction bytes except for constant pool 4896 references. This specification does not address the means by which 4897 compressors adapt to the presence and format of non-standard 4898 instructions. It simply requires decompressors to decode them 4899 correctly. <!-- 4900 [Considered defining a pseudo-attribute which allows a 4901 class to fully specify its constant pool ordering. 4902 This would allow attributes to be passed through without 4903 parsing, at the cost of some bloat. 4904 Did not seem worth the effort. Smart compressors can 4905 use 'V' elements to drive an arbitrary layout, and 4906 dumb compressors can just pass the file bytewise. 4907 --></p> 4908 <p>Here is a table of the specially rewritten transmission forms 4909 for instructions:</p> 4910 <table border="1" summary= 4911 "specially rewritten transmission forms for instructions"> 4912 <tr align="center"> 4913 <th id="instructions_oi">Original<br /> 4914 Instruction</th> 4915 <th id="instructions_op1">Operand</th> 4916 <th id="instructions_ti">Transmission<br /> 4917 Instruction</th> 4918 <th id="instructions_rr">Rewrite<br /> 4919 Required?</th> 4920 <th id="instructions_op2">Opcode</th> 4921 </tr> 4922 <tr> 4923 <td headers="instructions_oi">ldc</td> 4924 <td headers="instructions_op1">cp_String[i]</td> 4925 <td headers="instructions_ti">sldc</td> 4926 <td headers="instructions_rr">yes</td> 4927 <td headers="instructions_op2">18 <em>(=ldc)</em></td> 4928 </tr> 4929 <tr> 4930 <td headers="instructions_oi">ldc</td> 4931 <td headers="instructions_op1">cp_Class[i]</td> 4932 <td headers="instructions_ti">cldc</td> 4933 <td headers="instructions_rr">yes</td> 4934 <td headers="instructions_op2">233</td> 4935 </tr> 4936 <tr> 4937 <td headers="instructions_oi">ldc</td> 4938 <td headers="instructions_op1">cp_Int[i]</td> 4939 <td headers="instructions_ti">ildc</td> 4940 <td headers="instructions_rr">yes</td> 4941 <td headers="instructions_op2">234</td> 4942 </tr> 4943 <tr> 4944 <td headers="instructions_oi">ldc</td> 4945 <td headers="instructions_op1">cp_Float[i]</td> 4946 <td headers="instructions_ti">fldc</td> 4947 <td headers="instructions_rr">yes</td> 4948 <td headers="instructions_op2">235</td> 4949 </tr> 4950 <tr> 4951 <td headers="instructions_oi">ldc_w</td> 4952 <td headers="instructions_op1">cp_String[i]</td> 4953 <td headers="instructions_ti">sldc_w</td> 4954 <td headers="instructions_rr">yes</td> 4955 <td headers="instructions_op2">19 <em>(=ldc_w)</em></td> 4956 </tr> 4957 <tr> 4958 <td headers="instructions_oi">ldc_w</td> 4959 <td headers="instructions_op1">cp_Class[i]</td> 4960 <td headers="instructions_ti">cldc_w</td> 4961 <td headers="instructions_rr">yes</td> 4962 <td headers="instructions_op2">236</td> 4963 </tr> 4964 <tr> 4965 <td headers="instructions_oi">ldc_w</td> 4966 <td headers="instructions_op1">cp_Int[i]</td> 4967 <td headers="instructions_ti">ildc_w</td> 4968 <td headers="instructions_rr">yes</td> 4969 <td headers="instructions_op2">237</td> 4970 </tr> 4971 <tr> 4972 <td headers="instructions_oi">ldc_w</td> 4973 <td headers="instructions_op1">cp_Float[i]</td> 4974 <td headers="instructions_ti">fldc_w</td> 4975 <td headers="instructions_rr">yes</td> 4976 <td headers="instructions_op2">238</td> 4977 </tr> 4978 <tr> 4979 <td headers="instructions_oi">ldc2_w</td> 4980 <td headers="instructions_op1">cp_Long[i]</td> 4981 <td headers="instructions_ti">lldc2_w</td> 4982 <td headers="instructions_rr">yes</td> 4983 <td headers="instructions_op2">20 <em>(=ldc2_w)</em></td> 4984 </tr> 4985 <tr> 4986 <td headers="instructions_oi">ldc2_w</td> 4987 <td headers="instructions_op1">cp_Double[i]</td> 4988 <td headers="instructions_ti">dldc2_w</td> 4989 <td headers="instructions_rr">yes</td> 4990 <td headers="instructions_op2">239</td> 4991 </tr> 4992 <tr> 4993 <td headers="instructions_oi">ldc</td> 4994 <td headers="instructions_op1">cp_LoadableValue[i]</td> 4995 <td headers="instructions_ti">qldc</td> 4996 <td headers="instructions_rr">yes</td> 4997 <td headers="instructions_op2">240</td> 4998 </tr> 4999 <tr> 5000 <td headers="instructions_oi">ldc_w</td> 5001 <td headers="instructions_op1">cp_LoadableValue[i]</td> 5002 <td headers="instructions_ti">qldc_w</td> 5003 <td headers="instructions_rr">yes</td> 5004 <td headers="instructions_op2">241</td> 5005 </tr> 5006 <tr> 5007 <td headers="instructions_oi">getstatic</td> 5008 <td headers="instructions_op1"><em>(this class member)</em></td> 5009 <td headers="instructions_ti">getstatic_this</td> 5010 <td headers="instructions_rr">no</td> 5011 <td headers="instructions_op2">202</td> 5012 </tr> 5013 <tr> 5014 <td headers="instructions_oi">putstatic</td> 5015 <td headers="instructions_op1"><em>(this class member)</em></td> 5016 <td headers="instructions_ti">putstatic_this</td> 5017 <td headers="instructions_rr">no</td> 5018 <td headers="instructions_op2">203</td> 5019 </tr> 5020 <tr> 5021 <td headers="instructions_oi">getfield</td> 5022 <td headers="instructions_op1"><em>(this class member)</em></td> 5023 <td headers="instructions_ti">getfield_this</td> 5024 <td headers="instructions_rr">no</td> 5025 <td headers="instructions_op2">204</td> 5026 </tr> 5027 <tr> 5028 <td headers="instructions_oi">putfield</td> 5029 <td headers="instructions_op1"><em>(this class member)</em></td> 5030 <td headers="instructions_ti">putfield_this</td> 5031 <td headers="instructions_rr">no</td> 5032 <td headers="instructions_op2">205</td> 5033 </tr> 5034 <tr> 5035 <td headers="instructions_oi">invokevirtual</td> 5036 <td headers="instructions_op1"><em>(this class member)</em></td> 5037 <td headers="instructions_ti">invokevirtual_this</td> 5038 <td headers="instructions_rr">no</td> 5039 <td headers="instructions_op2">206</td> 5040 </tr> 5041 <tr> 5042 <td headers="instructions_oi">invokespecial</td> 5043 <td headers="instructions_op1"><em>(this class member)</em></td> 5044 <td headers="instructions_ti">invokespecial_this</td> 5045 <td headers="instructions_rr">no</td> 5046 <td headers="instructions_op2">207</td> 5047 </tr> 5048 <tr> 5049 <td headers="instructions_oi">invokestatic</td> 5050 <td headers="instructions_op1"><em>(this class member)</em></td> 5051 <td headers="instructions_ti">invokestatic_this</td> 5052 <td headers="instructions_rr">no</td> 5053 <td headers="instructions_op2">208</td> 5054 </tr> 5055 <tr> 5056 <td headers="instructions_oi">aload_0; getstatic</td> 5057 <td headers="instructions_op1"><em>(this class member)</em></td> 5058 <td headers="instructions_ti">aload_0_getstatic_this</td> 5059 <td headers="instructions_rr">no</td> 5060 <td headers="instructions_op2">209</td> 5061 </tr> 5062 <tr> 5063 <td headers="instructions_oi">aload_0; putstatic</td> 5064 <td headers="instructions_op1"><em>(this class member)</em></td> 5065 <td headers="instructions_ti">aload_0_putstatic_this</td> 5066 <td headers="instructions_rr">no</td> 5067 <td headers="instructions_op2">210</td> 5068 </tr> 5069 <tr> 5070 <td headers="instructions_oi">aload_0; getfield</td> 5071 <td headers="instructions_op1"><em>(this class member)</em></td> 5072 <td headers="instructions_ti">aload_0_getfield_this</td> 5073 <td headers="instructions_rr">no</td> 5074 <td headers="instructions_op2">211</td> 5075 </tr> 5076 <tr> 5077 <td headers="instructions_oi">aload_0; putfield</td> 5078 <td headers="instructions_op1"><em>(this class member)</em></td> 5079 <td headers="instructions_ti">aload_0_putfield_this</td> 5080 <td headers="instructions_rr">no</td> 5081 <td headers="instructions_op2">212</td> 5082 </tr> 5083 <tr> 5084 <td headers="instructions_oi">aload_0; invokevirtual</td> 5085 <td headers="instructions_op1"><em>(this class member)</em></td> 5086 <td headers="instructions_ti">aload_0_invokevirtual_this</td> 5087 <td headers="instructions_rr">no</td> 5088 <td headers="instructions_op2">213</td> 5089 </tr> 5090 <tr> 5091 <td headers="instructions_oi">aload_0; invokespecial</td> 5092 <td headers="instructions_op1"><em>(this class member)</em></td> 5093 <td headers="instructions_ti">aload_0_invokespecial_this</td> 5094 <td headers="instructions_rr">no</td> 5095 <td headers="instructions_op2">214</td> 5096 </tr> 5097 <tr> 5098 <td headers="instructions_oi">aload_0; invokestatic</td> 5099 <td headers="instructions_op1"><em>(this class member)</em></td> 5100 <td headers="instructions_ti">aload_0_invokestatic_this</td> 5101 <td headers="instructions_rr">no</td> 5102 <td headers="instructions_op2">215</td> 5103 </tr> 5104 <tr> 5105 <td headers="instructions_oi">getstatic</td> 5106 <td headers="instructions_op1"><em>(super class member)</em></td> 5107 <td headers="instructions_ti">getstatic_super</td> 5108 <td headers="instructions_rr">no</td> 5109 <td headers="instructions_op2">216</td> 5110 </tr> 5111 <tr> 5112 <td headers="instructions_oi">putstatic</td> 5113 <td headers="instructions_op1"><em>(super class member)</em></td> 5114 <td headers="instructions_ti">putstatic_super</td> 5115 <td headers="instructions_rr">no</td> 5116 <td headers="instructions_op2">217</td> 5117 </tr> 5118 <tr> 5119 <td headers="instructions_oi">getfield</td> 5120 <td headers="instructions_op1"><em>(super class member)</em></td> 5121 <td headers="instructions_ti">getfield_super</td> 5122 <td headers="instructions_rr">no</td> 5123 <td headers="instructions_op2">218</td> 5124 </tr> 5125 <tr> 5126 <td headers="instructions_oi">putfield</td> 5127 <td headers="instructions_op1"><em>(super class member)</em></td> 5128 <td headers="instructions_ti">putfield_super</td> 5129 <td headers="instructions_rr">no</td> 5130 <td headers="instructions_op2">219</td> 5131 </tr> 5132 <tr> 5133 <td headers="instructions_oi">invokevirtual</td> 5134 <td headers="instructions_op1"><em>(super class member)</em></td> 5135 <td headers="instructions_ti">invokevirtual_super</td> 5136 <td headers="instructions_rr">no</td> 5137 <td headers="instructions_op2">220</td> 5138 </tr> 5139 <tr> 5140 <td headers="instructions_oi">invokespecial</td> 5141 <td headers="instructions_op1"><em>(super class member)</em></td> 5142 <td headers="instructions_ti">invokespecial_super</td> 5143 <td headers="instructions_rr">no</td> 5144 <td headers="instructions_op2">221</td> 5145 </tr> 5146 <tr> 5147 <td headers="instructions_oi">invokestatic</td> 5148 <td headers="instructions_op1"><em>(super class member)</em></td> 5149 <td headers="instructions_ti">invokestatic_super</td> 5150 <td headers="instructions_rr">no</td> 5151 <td headers="instructions_op2">222</td> 5152 </tr> 5153 <tr> 5154 <td headers="instructions_oi">aload_0; getstatic</td> 5155 <td headers="instructions_op1"><em>(super class member)</em></td> 5156 <td headers="instructions_ti">aload_0_getstatic_super</td> 5157 <td headers="instructions_rr">no</td> 5158 <td headers="instructions_op2">223</td> 5159 </tr> 5160 <tr> 5161 <td headers="instructions_oi">aload_0; putstatic</td> 5162 <td headers="instructions_op1"><em>(super class member)</em></td> 5163 <td headers="instructions_ti">aload_0_putstatic_super</td> 5164 <td headers="instructions_rr">no</td> 5165 <td headers="instructions_op2">224</td> 5166 </tr> 5167 <tr> 5168 <td headers="instructions_oi">aload_0; getfield</td> 5169 <td headers="instructions_op1"><em>(super class member)</em></td> 5170 <td headers="instructions_ti">aload_0_getfield_super</td> 5171 <td headers="instructions_rr">no</td> 5172 <td headers="instructions_op2">225</td> 5173 </tr> 5174 <tr> 5175 <td headers="instructions_oi">aload_0; putfield</td> 5176 <td headers="instructions_op1"><em>(super class member)</em></td> 5177 <td headers="instructions_ti">aload_0_putfield_super</td> 5178 <td headers="instructions_rr">no</td> 5179 <td headers="instructions_op2">226</td> 5180 </tr> 5181 <tr> 5182 <td headers="instructions_oi">aload_0; invokevirtual</td> 5183 <td headers="instructions_op1"><em>(super class member)</em></td> 5184 <td headers="instructions_ti">aload_0_invokevirtual_super</td> 5185 <td headers="instructions_rr">no</td> 5186 <td headers="instructions_op2">227</td> 5187 </tr> 5188 <tr> 5189 <td headers="instructions_oi">aload_0; invokespecial</td> 5190 <td headers="instructions_op1"><em>(super class member)</em></td> 5191 <td headers="instructions_ti">aload_0_invokespecial_super</td> 5192 <td headers="instructions_rr">no</td> 5193 <td headers="instructions_op2">228</td> 5194 </tr> 5195 <tr> 5196 <td headers="instructions_oi">aload_0; invokestatic</td> 5197 <td headers="instructions_op1"><em>(super class member)</em></td> 5198 <td headers="instructions_ti">aload_0_invokestatic_super</td> 5199 <td headers="instructions_rr">no</td> 5200 <td headers="instructions_op2">229</td> 5201 </tr> 5202 <tr> 5203 <td headers="instructions_oi">invokespecial</td> 5204 <td headers="instructions_op1"><em>(this class 5205 <init>)</em></td> 5206 <td headers="instructions_ti">invokespecial_this_init</td> 5207 <td headers="instructions_rr">no</td> 5208 <td headers="instructions_op2">230</td> 5209 </tr> 5210 <tr> 5211 <td headers="instructions_oi">invokespecial</td> 5212 <td headers="instructions_op1"><em>(super class 5213 <init>)</em></td> 5214 <td headers="instructions_ti">invokespecial_super_init</td> 5215 <td headers="instructions_rr">no</td> 5216 <td headers="instructions_op2">231</td> 5217 </tr> 5218 <tr> 5219 <td headers="instructions_oi">invokespecial</td> 5220 <td headers="instructions_op1"><em>(new class 5221 <init>)</em></td> 5222 <td headers="instructions_ti">invokespecial_new_init</td> 5223 <td headers="instructions_rr">no</td> 5224 <td headers="instructions_op2">232</td> 5225 </tr> 5226 <tr> 5227 <td headers="instructions_oi">invokespecial</td> 5228 <td headers="instructions_op1">cp_Imethod[i]</td> 5229 <td headers="instructions_ti">invokespecial_int</td> 5230 <td headers="instructions_rr">yes</td> 5231 <td headers="instructions_op2">242</td> 5232 </tr> 5233 <tr> 5234 <td headers="instructions_oi">invokestatic</td> 5235 <td headers="instructions_op1">cp_Imethod[i]</td> 5236 <td headers="instructions_ti">invokestatic_int</td> 5237 <td headers="instructions_rr">yes</td> 5238 <td headers="instructions_op2">243</td> 5239 </tr> 5240 </table> 5241 <p>The <tt>qldc</tt> and <tt>qldc_w</tt> instructions use indexes 5242 into the constant pool group <tt>cp_LoadableValue</tt> to select 5243 arbitrary loadable constants. (These instructions may only appear 5244 when <tt>#archive_majver</tt> is 170 or higher. Early versions of 5245 the classfile format do not require them.) Decompressors are 5246 required to accept any constant reference as an operand to one of 5247 these instructions, but compressors are encouraged to transmit only 5248 constants which cannot be encoded by other variants of 5249 <tt>ldc</tt>, specifically elements of <tt>cp_MethodHandle</tt> and 5250 <tt>cp_MethodType</tt>.</p> 5251 <p>(Note: A previous version of this specification referred to the 5252 string-bearing variants of <tt>ldc</tt>, <tt>sldc</tt> and 5253 <tt>sldc_w</tt>, as <tt>aldc</tt> and <tt>aldc_w</tt>. Despite the 5254 new names, the code points and their interpretation have not 5255 changed. The old names are deprecated.)</p> 5256 <p>Every bytecode instruction is contained by a class, called the 5257 <em>current class</em>. The superclass (if any) of the current 5258 class is the <em>current super class</em>. The operand of the 5259 textually most recent "new" instruction (in the same method) is 5260 called the <em>current new class</em>.</p> 5261 <p>If an instruction refers to a field or method in the current 5262 class, it may (at the compressor's option) be rewritten for 5263 transmission as a corresponding opcode spelled with "_this". 5264 Likewise, an instruction referring to a field or method in the 5265 current super class may be rewritten as a corresponding opcode 5266 spelled with "_super". In either case, if the immediately preceding 5267 instruction is aload_0 (opcode 42), the transmission of that 5268 instruction may be suppressed by the compressor, and the 5269 corresponding opcode spelled with "aload_0_" selected instead; 5270 otherwise the "aload_0_" variant may not be selected.</p> 5271 <p>If an invokespecial instruction refers to a method named 5272 <init> in the current class, the current super class, or the 5273 current new class, the compressor may choose to rewrite it as an 5274 invokespecial_this_init, invokespecial_super_init, or 5275 invokespecial_new_init, respectively.</p> 5276 <p>If an invokespecial or an invokestatic instruction has an operand 5277 of type CONSTANT_InterfaceMethodref, then the compressor must transmit 5278 those methods using the pseudo-instructions invokespecial_int and 5279 invokestatic_int respectively. These instructions may only appear 5280 when <tt>#archive_majver</tt> is 171 or higher. 5281 <p>Field (resp. method) operands of rewritten instructions spelled 5282 with "_this" (but not "_init") are transmitted in the special band 5283 <tt>bc_thisfield</tt> (resp. <tt>bc_thismethod</tt>). The numbering 5284 of these operands is defined by taking the sequence of symbols in 5285 <tt>cp_Field</tt> (resp. <tt>cp_Method</tt>) and selecting only 5286 members of the current class. The resulting subset, without 5287 changing its order, is renumbered starting with zero. This provides 5288 a compact mapping of small integers to members of the current 5289 class.</p> 5290 <p>Likewise, operands of rewritten instructions spelled with 5291 "_super" (but not "_init") are transmitted in the 5292 <tt>bc_superfield</tt> or <tt>bc_supermethod</tt> band, and 5293 renumbered as a subset of <tt>cp_Field</tt> or <tt>cp_Method</tt>, 5294 selecting only members of the current super class.</p> 5295 <p>Finally, operands of the rewritten instructions spelled with 5296 "_init" are transmitted in the band <tt>bc_initref</tt>, and 5297 renumbered as a subset of <tt>cp_Method</tt>, selected according to 5298 the appropriate class (current, current super, or current new), and 5299 also selected to have the name <init>. (The index transmitted 5300 is usually very small; in effect it selects only the signature of 5301 the invoked method, and most classes possess only a few 5302 constructors.)</p> 5303 <p>Here is a table summarizing the transmission of instructions of 5304 more than one byte.</p> 5305 <table border="1" summary= 5306 "transmission instructions of more than one byte"> 5307 <tr align="center"> 5308 <th id="instructions_plus1_i">Instruction</th> 5309 <th id="instructions_plus1_o">Operand</th> 5310 <th id="instructions_plus1_t">Transmitted<br /> 5311 Value</th> 5312 <th id="instructions_plus1_b">Band</th> 5313 </tr> 5314 <tr> 5315 <td headers="instructions_plus1_i">bipush</td> 5316 <td headers="instructions_plus1_o">(byte) x</td> 5317 <td headers="instructions_plus1_t">x & 0xFF</td> 5318 <td headers="instructions_plus1_b"><tt>bc_byte</tt></td> 5319 </tr> 5320 <tr> 5321 <td headers="instructions_plus1_i">sipush</td> 5322 <td headers="instructions_plus1_o">(short) x</td> 5323 <td headers="instructions_plus1_t">x & 0xFFFF</td> 5324 <td headers="instructions_plus1_b"><tt>bc_short</tt></td> 5325 </tr> 5326 <tr> 5327 <td headers="instructions_plus1_i">ildc</td> 5328 <td headers="instructions_plus1_o">cp_Int[i]</td> 5329 <td headers="instructions_plus1_t">i</td> 5330 <td headers="instructions_plus1_b"><tt>bc_intref</tt></td> 5331 </tr> 5332 <tr> 5333 <td headers="instructions_plus1_i">fldc</td> 5334 <td headers="instructions_plus1_o">cp_Float[i]</td> 5335 <td headers="instructions_plus1_t">i</td> 5336 <td headers="instructions_plus1_b"><tt>bc_floatref</tt></td> 5337 </tr> 5338 <tr> 5339 <td headers="instructions_plus1_i">sldc</td> 5340 <td headers="instructions_plus1_o">cp_String[i]</td> 5341 <td headers="instructions_plus1_t">i</td> 5342 <td headers="instructions_plus1_b"><tt>bc_stringref</tt></td> 5343 </tr> 5344 <tr> 5345 <td headers="instructions_plus1_i">qldc</td> 5346 <td headers="instructions_plus1_o">cp_LoadableValue[i]</td> 5347 <td headers="instructions_plus1_t">i</td> 5348 <td headers="instructions_plus1_b"><tt>bc_loadablevalueref</tt></td> 5349 </tr> 5350 <tr> 5351 <td headers="instructions_plus1_i">cldc</td> 5352 <td headers="instructions_plus1_o">current class</td> 5353 <td headers="instructions_plus1_t">0</td> 5354 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5355 </tr> 5356 <tr> 5357 <td headers="instructions_plus1_i">cldc</td> 5358 <td headers="instructions_plus1_o">cp_Class[i]</td> 5359 <td headers="instructions_plus1_t">i+1</td> 5360 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5361 </tr> 5362 <tr> 5363 <td headers="instructions_plus1_i">ildc_w</td> 5364 <td headers="instructions_plus1_o">cp_Int[i]</td> 5365 <td headers="instructions_plus1_t">i</td> 5366 <td headers="instructions_plus1_b"><tt>bc_intref</tt></td> 5367 </tr> 5368 <tr> 5369 <td headers="instructions_plus1_i">fldc_w</td> 5370 <td headers="instructions_plus1_o">cp_Float[i]</td> 5371 <td headers="instructions_plus1_t">i</td> 5372 <td headers="instructions_plus1_b"><tt>bc_floatref</tt></td> 5373 </tr> 5374 <tr> 5375 <td headers="instructions_plus1_i">sldc_w</td> 5376 <td headers="instructions_plus1_o">cp_String[i]</td> 5377 <td headers="instructions_plus1_t">i</td> 5378 <td headers="instructions_plus1_b"><tt>bc_stringref</tt></td> 5379 </tr> 5380 <tr> 5381 <td headers="instructions_plus1_i">qldc_w</td> 5382 <td headers="instructions_plus1_o">cp_LoadableValue[i]</td> 5383 <td headers="instructions_plus1_t">i</td> 5384 <td headers="instructions_plus1_b"><tt>bc_loadablevalueref</tt></td> 5385 </tr> 5386 <tr> 5387 <td headers="instructions_plus1_i">cldc_w</td> 5388 <td headers="instructions_plus1_o">current class</td> 5389 <td headers="instructions_plus1_t">0</td> 5390 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5391 </tr> 5392 <tr> 5393 <td headers="instructions_plus1_i">cldc_w</td> 5394 <td headers="instructions_plus1_o">cp_Class[i]</td> 5395 <td headers="instructions_plus1_t">i+1</td> 5396 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5397 </tr> 5398 <tr> 5399 <td headers="instructions_plus1_i">lldc2_w</td> 5400 <td headers="instructions_plus1_o">cp_Long[i]</td> 5401 <td headers="instructions_plus1_t">i</td> 5402 <td headers="instructions_plus1_b"><tt>bc_long</tt></td> 5403 </tr> 5404 <tr> 5405 <td headers="instructions_plus1_i">dldc2_w</td> 5406 <td headers="instructions_plus1_o">cp_Double[i]</td> 5407 <td headers="instructions_plus1_t">i</td> 5408 <td headers="instructions_plus1_b"><tt>bc_double</tt></td> 5409 </tr> 5410 <tr> 5411 <td headers="instructions_plus1_i">*load</td> 5412 <td headers="instructions_plus1_o">locals[i]</td> 5413 <td headers="instructions_plus1_t">i</td> 5414 <td headers="instructions_plus1_b"><tt>bc_local</tt></td> 5415 </tr> 5416 <tr> 5417 <td headers="instructions_plus1_i">*store</td> 5418 <td headers="instructions_plus1_o">locals[i]</td> 5419 <td headers="instructions_plus1_t">i</td> 5420 <td headers="instructions_plus1_b"><tt>bc_local</tt></td> 5421 </tr> 5422 <tr> 5423 <td headers="instructions_plus1_i">ret</td> 5424 <td headers="instructions_plus1_o">locals[i]</td> 5425 <td headers="instructions_plus1_t">i</td> 5426 <td headers="instructions_plus1_b"><tt>bc_local</tt></td> 5427 </tr> 5428 <tr> 5429 <td headers="instructions_plus1_i">iinc</td> 5430 <td headers="instructions_plus1_o">locals[i]</td> 5431 <td headers="instructions_plus1_t">i</td> 5432 <td headers="instructions_plus1_b"><tt>bc_local</tt></td> 5433 </tr> 5434 <tr> 5435 <td headers="instructions_plus1_i">iinc (not wide)</td> 5436 <td headers="instructions_plus1_o">(byte) x</td> 5437 <td headers="instructions_plus1_t">x & 0xFF</td> 5438 <td headers="instructions_plus1_b"><tt>bc_byte</tt></td> 5439 </tr> 5440 <tr> 5441 <td headers="instructions_plus1_i">iinc (wide)</td> 5442 <td headers="instructions_plus1_o">(short) x</td> 5443 <td headers="instructions_plus1_t">x & 0xFFFF</td> 5444 <td headers="instructions_plus1_b"><tt>bc_short</tt></td> 5445 </tr> 5446 <tr> 5447 <td headers="instructions_plus1_i">if**</td> 5448 <td headers="instructions_plus1_o">pc</td> 5449 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5450 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5451 </tr> 5452 <tr> 5453 <td headers="instructions_plus1_i">if_**</td> 5454 <td headers="instructions_plus1_o">pc</td> 5455 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5456 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5457 </tr> 5458 <tr> 5459 <td headers="instructions_plus1_i">goto</td> 5460 <td headers="instructions_plus1_o">pc</td> 5461 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5462 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5463 </tr> 5464 <tr> 5465 <td headers="instructions_plus1_i">jsr</td> 5466 <td headers="instructions_plus1_o">pc</td> 5467 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5468 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5469 </tr> 5470 <tr> 5471 <td headers="instructions_plus1_i">goto_w</td> 5472 <td headers="instructions_plus1_o">pc</td> 5473 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5474 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5475 </tr> 5476 <tr> 5477 <td headers="instructions_plus1_i">jsr_w</td> 5478 <td headers="instructions_plus1_o">pc</td> 5479 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5480 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5481 </tr> 5482 <tr> 5483 <td headers="instructions_plus1_i">tableswitch</td> 5484 <td headers="instructions_plus1_o">case count</td> 5485 <td headers="instructions_plus1_t">count</td> 5486 <td headers="instructions_plus1_b"><tt>bc_case_count</tt></td> 5487 </tr> 5488 <tr> 5489 <td headers="instructions_plus1_i">tableswitch</td> 5490 <td headers="instructions_plus1_o">default pc</td> 5491 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5492 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5493 </tr> 5494 <tr> 5495 <td headers="instructions_plus1_i">tableswitch</td> 5496 <td headers="instructions_plus1_o">first case value</td> 5497 <td headers="instructions_plus1_t">value</td> 5498 <td headers="instructions_plus1_b"><tt>bc_case_value</tt></td> 5499 </tr> 5500 <tr> 5501 <td headers="instructions_plus1_i">tableswitch</td> 5502 <td headers="instructions_plus1_o">each case pc</td> 5503 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5504 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5505 </tr> 5506 <tr> 5507 <td headers="instructions_plus1_i">lookupswitch</td> 5508 <td headers="instructions_plus1_o">case count</td> 5509 <td headers="instructions_plus1_t">count</td> 5510 <td headers="instructions_plus1_b"><tt>bc_case_count</tt></td> 5511 </tr> 5512 <tr> 5513 <td headers="instructions_plus1_i">lookupswitch</td> 5514 <td headers="instructions_plus1_o">default pc</td> 5515 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5516 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5517 </tr> 5518 <tr> 5519 <td headers="instructions_plus1_i">lookupswitch</td> 5520 <td headers="instructions_plus1_o">each case value</td> 5521 <td headers="instructions_plus1_t">value</td> 5522 <td headers="instructions_plus1_b"><tt>bc_case_value</tt></td> 5523 </tr> 5524 <tr> 5525 <td headers="instructions_plus1_i">lookupswitch</td> 5526 <td headers="instructions_plus1_o">each case pc</td> 5527 <td headers="instructions_plus1_t"><em>(delta/renumbered)</em></td> 5528 <td headers="instructions_plus1_b"><tt>bc_label</tt></td> 5529 </tr> 5530 <tr> 5531 <td headers="instructions_plus1_i">new</td> 5532 <td headers="instructions_plus1_o">current class</td> 5533 <td headers="instructions_plus1_t">0</td> 5534 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5535 </tr> 5536 <tr> 5537 <td headers="instructions_plus1_i">new</td> 5538 <td headers="instructions_plus1_o">cp_Class[i]</td> 5539 <td headers="instructions_plus1_t">1+i</td> 5540 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5541 </tr> 5542 <tr> 5543 <td headers="instructions_plus1_i">newarray</td> 5544 <td headers="instructions_plus1_o">type code</td> 5545 <td headers="instructions_plus1_t">value</td> 5546 <td headers="instructions_plus1_b"><tt>bc_byte</tt></td> 5547 </tr> 5548 <tr> 5549 <td headers="instructions_plus1_i">anewarray</td> 5550 <td headers="instructions_plus1_o">current class</td> 5551 <td headers="instructions_plus1_t">0</td> 5552 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5553 </tr> 5554 <tr> 5555 <td headers="instructions_plus1_i">anewarray</td> 5556 <td headers="instructions_plus1_o">cp_Class[i]</td> 5557 <td headers="instructions_plus1_t">1+i</td> 5558 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5559 </tr> 5560 <tr> 5561 <td headers="instructions_plus1_i">checkcast</td> 5562 <td headers="instructions_plus1_o">current class</td> 5563 <td headers="instructions_plus1_t">0</td> 5564 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5565 </tr> 5566 <tr> 5567 <td headers="instructions_plus1_i">checkcast</td> 5568 <td headers="instructions_plus1_o">cp_Class[i]</td> 5569 <td headers="instructions_plus1_t">1+i</td> 5570 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5571 </tr> 5572 <tr> 5573 <td headers="instructions_plus1_i">instanceof</td> 5574 <td headers="instructions_plus1_o">current class</td> 5575 <td headers="instructions_plus1_t">0</td> 5576 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5577 </tr> 5578 <tr> 5579 <td headers="instructions_plus1_i">instanceof</td> 5580 <td headers="instructions_plus1_o">cp_Class[i]</td> 5581 <td headers="instructions_plus1_t">1+i</td> 5582 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5583 </tr> 5584 <tr> 5585 <td headers="instructions_plus1_i">multianewarray</td> 5586 <td headers="instructions_plus1_o">cp_Class[i]</td> 5587 <td headers="instructions_plus1_t">1+i</td> 5588 <td headers="instructions_plus1_b"><tt>bc_classref</tt></td> 5589 </tr> 5590 <tr> 5591 <td headers="instructions_plus1_i">multianewarray</td> 5592 <td headers="instructions_plus1_o">rank</td> 5593 <td headers="instructions_plus1_t">rank & 0xFF</td> 5594 <td headers="instructions_plus1_b"><tt>bc_byte</tt></td> 5595 </tr> 5596 <tr> 5597 <td headers="instructions_plus1_i">getstatic</td> 5598 <td headers="instructions_plus1_o">cp_Field[i]</td> 5599 <td headers="instructions_plus1_t">i</td> 5600 <td headers="instructions_plus1_b"><tt>bc_fieldref</tt></td> 5601 </tr> 5602 <tr> 5603 <td headers="instructions_plus1_i">putstatic</td> 5604 <td headers="instructions_plus1_o">cp_Field[i]</td> 5605 <td headers="instructions_plus1_t">i</td> 5606 <td headers="instructions_plus1_b"><tt>bc_fieldref</tt></td> 5607 </tr> 5608 <tr> 5609 <td headers="instructions_plus1_i">getfield</td> 5610 <td headers="instructions_plus1_o">cp_Field[i]</td> 5611 <td headers="instructions_plus1_t">i</td> 5612 <td headers="instructions_plus1_b"><tt>bc_fieldref</tt></td> 5613 </tr> 5614 <tr> 5615 <td headers="instructions_plus1_i">putfield</td> 5616 <td headers="instructions_plus1_o">cp_Field[i]</td> 5617 <td headers="instructions_plus1_t">i</td> 5618 <td headers="instructions_plus1_b"><tt>bc_fieldref</tt></td> 5619 </tr> 5620 <tr> 5621 <td headers="instructions_plus1_i">invokevirtual</td> 5622 <td headers="instructions_plus1_o">cp_Method[i]</td> 5623 <td headers="instructions_plus1_t">i</td> 5624 <td headers="instructions_plus1_b"><tt>bc_methodref</tt></td> 5625 </tr> 5626 <tr> 5627 <td headers="instructions_plus1_i">invokespecial</td> 5628 <td headers="instructions_plus1_o">cp_Method[i]</td> 5629 <td headers="instructions_plus1_t">i</td> 5630 <td headers="instructions_plus1_b"><tt>bc_methodref</tt></td> 5631 </tr> 5632 <tr> 5633 <td headers="instructions_plus1_i">invokestatic</td> 5634 <td headers="instructions_plus1_o">cp_Method[i]</td> 5635 <td headers="instructions_plus1_t">i</td> 5636 <td headers="instructions_plus1_b"><tt>bc_methodref</tt></td> 5637 </tr> 5638 <tr> 5639 <td headers="instructions_plus1_i">invokeinterface</td> 5640 <td headers="instructions_plus1_o">cp_Imethod[i]</td> 5641 <td headers="instructions_plus1_t">i</td> 5642 <td headers="instructions_plus1_b"><tt>bc_imethodref</tt></td> 5643 </tr> 5644 <tr> 5645 <td headers="instructions_plus1_i">invokespecial_int</td> 5646 <td headers="instructions_plus1_o">cp_Imethod[i]</td> 5647 <td headers="instructions_plus1_t">i</td> 5648 <td headers="instructions_plus1_b"><tt>bc_imethodref</tt></td> 5649 </tr> 5650 <tr> 5651 <td headers="instructions_plus1_i">invokestatic_int</td> 5652 <td headers="instructions_plus1_o">cp_Imethod[i]</td> 5653 <td headers="instructions_plus1_t">i</td> 5654 <td headers="instructions_plus1_b"><tt>bc_imethodref</tt></td> 5655 </tr> 5656 <tr> 5657 <td headers="instructions_plus1_i">invokedynamic</td> 5658 <td headers="instructions_plus1_o">cp_InvokeDynamic[i]</td> 5659 <td headers="instructions_plus1_t">i</td> 5660 <td headers="instructions_plus1_b"><tt>bc_indyref</tt></td> 5661 </tr> 5662 <tr> 5663 <td headers="instructions_plus1_i">**_this</td> 5664 <td headers="instructions_plus1_o">this_fields[i]</td> 5665 <td headers="instructions_plus1_t">i</td> 5666 <td headers="instructions_plus1_b"><tt>bc_thisfield</tt></td> 5667 </tr> 5668 <tr> 5669 <td headers="instructions_plus1_i">**_this</td> 5670 <td headers="instructions_plus1_o">this_methods[i]</td> 5671 <td headers="instructions_plus1_t">i</td> 5672 <td headers="instructions_plus1_b"><tt>bc_thismethod</tt></td> 5673 </tr> 5674 <tr> 5675 <td headers="instructions_plus1_i">**_super</td> 5676 <td headers="instructions_plus1_o">super_fields[i]</td> 5677 <td headers="instructions_plus1_t">i</td> 5678 <td headers="instructions_plus1_b"><tt>bc_superfield</tt></td> 5679 </tr> 5680 <tr> 5681 <td headers="instructions_plus1_i">**_super</td> 5682 <td headers="instructions_plus1_o">super_methods[i]</td> 5683 <td headers="instructions_plus1_t">i</td> 5684 <td headers="instructions_plus1_b"><tt>bc_supermethod</tt></td> 5685 </tr> 5686 <tr> 5687 <td headers="instructions_plus1_i">invokespecial_this_init</td> 5688 <td headers="instructions_plus1_o">this_constructors[i]</td> 5689 <td headers="instructions_plus1_t">i</td> 5690 <td headers="instructions_plus1_b"><tt>bc_initref</tt></td> 5691 </tr> 5692 <tr> 5693 <td headers="instructions_plus1_i">invokespecial_super_init</td> 5694 <td headers="instructions_plus1_o">super_constructors[i]</td> 5695 <td headers="instructions_plus1_t">i</td> 5696 <td headers="instructions_plus1_b"><tt>bc_initref</tt></td> 5697 </tr> 5698 <tr> 5699 <td headers="instructions_plus1_i">invokespecial_new_init</td> 5700 <td headers="instructions_plus1_o">new_constructors[i]</td> 5701 <td headers="instructions_plus1_t">i</td> 5702 <td headers="instructions_plus1_b"><tt>bc_initref</tt></td> 5703 </tr> 5704 </table> 5705 <a name="encodings" id="encodings"></a> <a name="tocSpBaCo" id= 5706 "tocSpBaCo"></a> 5707 <h2>6. Specification of Band Coding</h2> 5708 A Pack200 band consists of a sequence of small integers, each of 5709 which is representable in 32 bits. Depending on the intended use of 5710 these numbers, they may be interpreted to possess a twos-complement 5711 sign. 5712 <p>Each integer is coded for transmission as a byte sequence, using 5713 between one and five bytes, according to a previously determined 5714 encoding. The encoding may by a primary encoding for the current 5715 band as specified as part of this Pack200 archive format 5716 specification, or the encoding may depend on information 5717 transmitted before the occurrence of the encoded integer.</p> 5718 <p>(Note: In this account of encodings, bytes are indivisible 5719 octets which express unsigned values in [0,255].)</p> 5720 <a name="tocEnSmWhNu" id="tocEnSmWhNu"></a> 5721 <h3>6.1. Encoding of Small Whole Numbers</h3> 5722 There is a small but flexible set of possible encodings allowed by 5723 the archive. They are all based on a two-parameter scheme of 5724 codings for small unsigned integers, which is further parameterized 5725 by options for sign representation and delta encoding, and by 5726 special modes for slowly varying encodings, and for the compact 5727 renaming of frequent values. <a name="tocScMuCo" id= 5728 "tocScMuCo"></a> 5729 <h4>6.1.1. Scheme of Multiple Codings</h4> 5730 The encoding of a small whole number depends on two independent 5731 parameters B and H, and a derived parameter L: 5732 <table border="1" summary="multiple coding scheme"> 5733 <tr align="center"> 5734 <th id="multiple_coding_scheme_n">Name</th> 5735 <th id="multiple_coding_scheme_r">Range</th> 5736 <th id="multiple_coding_scheme_m">Meaning</th> 5737 </tr> 5738 <tr> 5739 <td headers="multiple_coding_scheme_n">B</td> 5740 <td headers="multiple_coding_scheme_r">[1..5]</td> 5741 <td headers="multiple_coding_scheme_m">maximum byte length</td> 5742 </tr> 5743 <tr> 5744 <td headers="multiple_coding_scheme_n">H</td> 5745 <td headers="multiple_coding_scheme_r">[1..256]</td> 5746 <td headers="multiple_coding_scheme_m">number of high byte 5747 values</td> 5748 </tr> 5749 <tr> 5750 <td headers="multiple_coding_scheme_n">L</td> 5751 <td headers="multiple_coding_scheme_r">[0..255]</td> 5752 <td headers="multiple_coding_scheme_m">number of low byte values, 5753 defined as (256-H)</td> 5754 </tr> 5755 </table> 5756 <p>Given any two values B and H, there is a coding (B,H) which 5757 establishes a one-to-one correspondence between an initial sequence 5758 of non-negative integers, and an "encoding sets" of short sequences 5759 of bytes.</p> 5760 <p>Moreover, no byte sequence in the encoding set is a proper 5761 prefix of another byte sequence in the same set. prefix. This 5762 means, informally, that encodings are self-sizing, or 5763 "parseable".</p> 5764 <p>Also, the encoding set is as full as possible, so that every 5765 long-enough sequence of bytes begins with a unique prefix of bytes 5766 drawn from the encoding set. In particular, every sequence of B 5767 bytes has a (unique) prefix in the encoding set for the (B,H) 5768 coding.</p> 5769 <a name="tocDeEnBySe" id="tocDeEnBySe"></a> 5770 <h4>6.1.2. Definition of Encoding Byte Sequences</h4> 5771 Relative to a given (B,H) coding, we say that a byte is "high" if 5772 its value is in the range <tt>[256-H..255]</tt>. We also say that a 5773 byte is "low" if L is positive and the byte's value is in the range 5774 <tt>[0..L-1]</tt> 5775 <p>Given a (B,H) coding, a sequence of bytes is in its encoding set 5776 if and only if all of the following are true:</p> 5777 <ul> 5778 <li>the sequence contains at least one and no more than B 5779 bytes</li> 5780 <li>all bytes except the last are "high"</li> 5781 <li>either the last byte is "low", or else the sequence has B 5782 bytes</li> 5783 </ul> 5784 <p>As a consequence of this definition, the encoding set be 5785 regarded as satisfying this regular expression, in terms of high 5786 and low bytes:</p> 5787 <pre class="codblock"> 5788 encoding_set = (high* low) | (high)^B 5789 </pre> 5790 <p>(Note: In this specification the up-caret sign '^' denotes 5791 exponentiation, either of regular expressions as above, or of 5792 numbers.)</p> 5793 <p>If n is less than B then the number of (B,H) encodings of length 5794 exactly n is <tt>(H^(n-1) * L)</tt>. The number of (B,H) encodings 5795 of length exactly B is <tt>(H^(B-1) * (L+H))</tt>. The sum of these 5796 values for all n in <tt>[1..B]</tt> is the total size of the 5797 encoding set for a (B,H) coding. It is called <em>Card(B,H)</em> 5798 and is therefore defined as:</p> 5799 <pre class="codeblock"> 5800 Card(B,H) = (L * (1-H^B)/(1-H)) + H^B 5801 if H>1, or else 5802 Card(B,1) = B*255+1 5803 5804 </pre> 5805 <p>If H is 256, there are no low bytes, and the encoding set 5806 consists of all possible sequences of exactly B bytes, and 5807 Card(B,H) is <tt>256^B</tt>.</p> 5808 <p>Otherwise, the encoding set consists of sequences of various 5809 lengths, from 1 to B inclusive. In particular, there are L one-byte 5810 sequences. We will use these elsewhere to encode the "favored" 5811 integers of the highest frequency. Note that the encoding rules 5812 specified elsewhere in this document are designed to produce 5813 smaller integers more frequently than larger ones.</p> 5814 <p>Note that L can be viewed as a "sharpness" parameter, expressing 5815 the sharpness of the distribution about zero of the expected values 5816 to be encoded. The larger L is, the more the encoding favors 5817 distributions of values which are close to zero, and rarely far 5818 from it. Larger H values favor "flatter" distributions, up to 5819 H=256, L=0, which favorably encodes completely random data within 5820 the range of the coding.</p> 5821 <a name="tocDeDeWhNuVa" id="tocDeDeWhNuVa"></a> 5822 <h4>6.1.3. Definition of Decoded Whole Number Values</h4> 5823 The range of a (B,H) coding is the integers in 5824 <tt>[0..Card(B,H)-1]</tt>. (Note that this range applies only to 5825 the unsigned codings introduced so far in this section.) 5826 <p>Given the sequence of N byte values b[0] .. b[N-1], the 5827 sorting-based definition given above implies that the decoded 5828 integer value of this byte sequence is the little-endian base-H 5829 scaled sum of the bytes, and is called <em>Decode(B,H; b)</em>:</p> 5830 <pre class="codeblock"> 5831 Decode(B,H; b[*]) = Sum[0<=i<N]( b[i] * H^i ) 5832 5833 </pre> 5834 <p>As a consequence of this definition, each byte sequence in the 5835 encoding set corresponds uniquely to an arithmetic integer value in 5836 that range. This correspondence may be observed by ordering the 5837 byte sequences first by length, and second according to their 5838 antilexicographic (little-endian) order. Each element in resulting 5839 sequence decodes into its own zero-based index within the 5840 sequence.</p> 5841 <p>Note that the number zero is always encoded by a sequence of B 5842 zero bytes (if H is 256) or else by single zero byte.</p> 5843 <p>The largest encoded arithmetic value is always encoded by a 5844 sequence of B bytes of value 255.</p> 5845 <p>Note that the (B,H) encodings (1,256), (2,256), and (4,256) are 5846 identical with the conventional little-endian representations of 5847 unsigned bytes, unsigned 16-bit integers, and unsigned 32-bit 5848 integers.</p> 5849 <p>Note that some may represent arithmetic values greater than 5850 <tt>2^31-1</tt> or even <tt>2^32-1</tt>. This is a feature of the 5851 (B,H) coding scheme. (But sometimes intermediate 64-bit values are 5852 required when multiple sign bits are being used, as described 5853 below. The rules given below for signed values require the 5854 compressor to emit the simplest encoding that will suffice to 5855 transmit the required 32-bit integer, even if more complex 5856 sequences would produce the same 32-bit value, after 5857 truncation.)</p> 5858 <p>Note that implementations are not always free to truncate 5859 intermediate values when computing (B,H) coding values. However, 5860 the final decoded values (after restoration of signs) will always 5861 fit in 32 bits, as described in the next section.</p> 5862 <a name="tocEnSiIn" id="tocEnSiIn"></a> 5863 <h4>6.2. Encoding of Signed Integers</h4> 5864 In order to encode signed 32-bit numbers we add another parameter 5865 to the (B,H) coding scheme. 5866 <table border="1" summary="encoding of signed integers"> 5867 <tr align="center"> 5868 <th id="signed_integers_encoding_n">Name</th> 5869 <th id="signed_integers_encoding_r">Range</th> 5870 <th id="signed_integers_encoding_m">Meaning</th> 5871 </tr> 5872 <tr> 5873 <td headers="signed_integers_encoding_n">B</td> 5874 <td headers="signed_integers_encoding_r">[1..5]</td> 5875 <td headers="signed_integers_encoding_m">maximum byte length</td> 5876 </tr> 5877 <tr> 5878 <td headers="signed_integers_encoding_n">H</td> 5879 <td headers="signed_integers_encoding_r">[1..256]</td> 5880 <td headers="signed_integers_encoding_m">number of high byte 5881 values</td> 5882 </tr> 5883 <tr> 5884 <td headers="signed_integers_encoding_n">L</td> 5885 <td headers="signed_integers_encoding_r">[0..255]</td> 5886 <td headers="signed_integers_encoding_m">number of low byte values, 5887 defined as (256-H)</td> 5888 </tr> 5889 <tr> 5890 <td headers="signed_integers_encoding_n">S</td> 5891 <td headers="signed_integers_encoding_r">[0..2]</td> 5892 <td headers="signed_integers_encoding_m">number of sign bits</td> 5893 </tr> 5894 </table> 5895 <p>The whole number U obtained from a (B,H) coding is converted to 5896 a signed 32-bit value X in a manner which depends on the parameter 5897 S. This process is called <em>sign conversion</em>.</p> 5898 <p>Informally, sign conversion is performed by 32-bit truncation if 5899 S=0. Otherwise, the low-order bits of U are collectively treated as 5900 a sign bit, so that X will be negative only if all sign bits are 5901 set. The two conversions from U to positive X and U to negative X 5902 are independently dense and monotonic in opposite directions, as 5903 defined below.</p> 5904 <p>Unlike the (B,H) coding, a (B,H,S) coding represents only 5905 numbers in a specifically defined range, which is never larger than 5906 <tt>[-2^31..2^31-1]</tt>.</p> 5907 <p>In what follows, for each (B,H,S) coding, we define 5908 Range(B,H,S), and the method used to represent 32-bit signed values 5909 with that coding.</p> 5910 <p>A (B,H) encoding byte sequence is not a legal input to a 5911 corresponding (B,H,S) coding if it represents a whole number U 5912 which does not convert into the range of the (B,H,S) coding. Also, 5913 if there are two byte sequences encoding values U1 and U2 which 5914 both map into the same point X in the signed range, only the byte 5915 sequence for the smaller of U1 and U2 is legal.</p> 5916 <p>Thus, a (B,H,S) coding may have a smaller cardinality than the 5917 corresponding (B,H) coding, due to illegal encoding byte 5918 sequences.</p> 5919 <p>The range of a (B,H,S) coding contains all 32-bit signed 5920 integers <tt>[-2^31..2^31-1]</tt> if Card(B,H) is <tt>2^32</tt> or 5921 more. (Negative values are represented by 31-bit unsigned 5922 overflow.) If the coding encodes fewer unsigned values, the top of 5923 its range is clipped to <tt>2^31-1</tt>, and the bottom of its 5924 range is clipped to <tt>-2^31</tt>.</p> 5925 <p>More precisely, the range of a (B,H,S) coding is called 5926 <em>Range(B,H,S)</em> and is defined (partially, for S=0) as:</p> 5927 <pre class="codeblock"> 5928 Range(B,H,S) = [-2^31..2^31-1] 5929 if S=0, Card(B,H) >= 2^32, or 5930 Range(B,H,S) = [0..2^31-1] 5931 if S=0, 2^31 < Card(B,H) < 2^32, or else 5932 Range(B,H,S) = [0..Card(B,H)-1] 5933 if S=0, Card(B,H) <= 2^31 5934 5935 </pre> 5936 A compressor is not allowed to emit a byte sequence which, when 5937 interpreted according to the current coding, decodes to a value 5938 outside of that coding's range. 5939 <p>(Note that decompressors can produce arbitrary answers for 5940 out-of-range codings, since compressors are not allowed to emit 5941 them. This allows decompressors to use 32-bit arithmetic for most 5942 calculations, ignoring the possibility of undesired wraparond.)</p> 5943 <p>If S>0, the decoding of a byte sequence is performed first by 5944 decoding it as a (B,H) coding, and then by converting the decoded 5945 whole number into a signed 32-bit number. This sign conversion 5946 depends only on the arithmetic value U obtained from the (B,H) 5947 coding, and on the value of S. The arithmetic value must be 5948 preserved beyond 32 bits of precision, if the sign conversion will 5949 produce a value within the range of the coding. If the cardinality 5950 of the (B,H) coding is <tt>2^32</tt> or more, the (B,H,S) coding 5951 produces all possible signed 32-bit negative values, by 32-bit 5952 truncation of the intermediate unsigned whole number. The 5953 intermediate unsigned arithmetic can be carried out (with some 5954 care) using 32-bit unsigned numbers, or it can be carried out on 5955 64-bit signed or unsigned numbers.</p> 5956 <p>More precisely, the sign conversion operation 5957 <em>SignConvert(S;U)</em> is defined as:</p> 5958 <pre class="codeblock"> 5959 SignConvert(S; U) = Cast32(U) 5960 if S==0; or 5961 SignConvert(S; U) = U - Floor(U / 2^S) 5962 if S>0, (U % 2^S) < 2^S-1, Card(B,H) < 2^32 5963 SignConvert(S; U) = Cast32(U - Floor(U / 2^S)) 5964 if S>0, (U % 2^S) < 2^S-1, Card(B,H) >= 2^32 5965 SignConvert(S; U) = -Floor(U / 2^S)-1 5966 if S>0, (U % 2^S) == 2^S-1 5967 5968 </pre> 5969 The conversion from a large unsigned number of a negative 32-bit 5970 number via wraparound is simply the familiar down-cast to a signed 5971 32-bit int. It may be defined mathematically as: 5972 <pre class="codeblock"> 5973 Cast32(U) = ((U + 2^31) mod 2^32) - 2^31 5974 5975 </pre> 5976 <a name="tocFuDiSiCo" id="tocFuDiSiCo"></a> 5977 <h5>6.2.1. Further Discussion of Sign Conversion</h5> 5978 Note that sign conversion always maps zero to zero. The reader may 5979 also verify that, if S>0, the range of SignConvert includes 5980 [-1..1], and that it is dense and monotonic in any wholly positive 5981 or wholly negative sub-range. 5982 <p>As a consequence of the definition of <tt>SignConvert(S;U)</tt>, 5983 the S low-order bits of U function as a sign bit. In effect, U is 5984 partitioned into a sign field U0 (consisting of the S low-order 5985 bits) and a significand U1 (consisting of all other bits of U).</p> 5986 <p>In this alternative view of the definition of 5987 <tt>SignConvert</tt>, if all S bits of U0 are set, then the decoded 5988 signed value is the ones complement of U1. (Since this includes the 5989 indefinite number of zero high-order bits of U, the resulting value 5990 is arithmetically negative.)</p> 5991 <p>Otherwise, if some of the S bits of U0 are clear, then the 5992 significand U1 is scaled by the number of possible values of U0 5993 (i.e., (2^2)-1 if S is 2) and U0 is added back in.</p> 5994 <p>This provides a one-to-one correspondence between some portion 5995 of the arithmetic interval <tt>[0..Card(B,H)-1]</tt> and 5996 <tt>Range(B,H,S)</tt>.</p> 5997 <p>The integers "favored" by this encoding are those of small 5998 magnitude, but they can have either sign. If S is one, the encoding 5999 has a balanced number of positive and negative favored values. If S 6000 is two (or more), the encoding is skewed toward positive numbers, 6001 but also favors a few negative numbers. We use such codings 6002 elsewhere to encode values, such as branch displacements or deltas 6003 of mostly-sorted data, which are usually positive but sometimes 6004 negative.</p> 6005 <p>Note that if S=1, this definition of sign conversion is 6006 equivalent to an unsigned right shift followed by an exclusive-or 6007 of the sign bit with all remaining bits:</p> 6008 <pre class="codeblock"> 6009 SignConvert(1; U) = (U >>> 1) ^ -(U & 1) 6010 6011 </pre> 6012 <p>For S>0, Range(B,H,S) is simply defined as the intersection 6013 of the 32-bit signed range <tt>[-2^31..2^31-1]</tt> with the set 6014 <tt>SignConvert(S; [0..Card(B,H)-1])</tt>, obtained by element-wise 6015 application of sign conversion to every arithmetically 6016 representable value of (B,H). Therefore, we can complete the 6017 definition of <em>Range</em> as follows:</p> 6018 <pre class="codeblock"> 6019 Range(B,H,S) = [-2^31..2^31-1] 6020 if Card(B,H) >= 2^32, or 6021 Range(B,H,S) = [0..2^31-1] 6022 if S=0, 2^31 < Card(B,H) < 2^32, or else 6023 Range(B,H,S) = [0..Card(B,H)-1] 6024 if S=0, Card(B,H) <= 2^31 6025 6026 Range(B,H,S) = [max( -2^31, min SignConvert(S; Range(B,H,0)) ) 6027 .. min( 2^31-1, max SignConvert(S; Range(B,H,0)) )] 6028 6029 </pre> 6030 <p>(Note: When computing the bounds of a signed encoding (B,H,S), 6031 it is useful to start with the largest unsigned value M of (B,H,0) 6032 and perform sign-conversion on M, M-1, M-2, etc., noting the first 6033 positive and the first negative value to be encountered. These will 6034 be the inclusive bounds of the signed encoding's range.)</p> 6035 <a name="tocAttCod" id="tocAttCod"></a> 6036 <h4>6.3. Attributes of Codings</h4> 6037 The cardinality of a (B,H) coding was defined above: 6038 <pre class="codeblock"> 6039 Card(B,H) = (L * (1-H^B)/(1-H)) + H^B 6040 6041 </pre> 6042 <p>The cardinality of a (B,H,S) coding is determined by that of its 6043 range:</p> 6044 <pre class="codeblock"> 6045 Card(B,H,S) = Card Range(B,H,S) <= Card(B,H) 6046 6047 </pre> 6048 <p>As defined, the range of any coding (B,H,S) is dense about zero 6049 and can therefore be expressed as a closed interval:</p> 6050 <pre class="codeblock"> 6051 Range(B,H,S) = [Min(B,H,S)..Max(B,H,S)] 6052 -2^31 <= Min(B,H,S) <= 0 6053 0 < Max(B,H,S) <= 2^31-1 6054 6055 </pre> 6056 <p>Certain additional attributes can be predicated of codings. A 6057 coding can either be signed or not, and it can be a full-range 6058 coding, or a sub-range coding (or neither).</p> 6059 <p>A (B,H,S) coding is <em>signed</em> if it can encode at least 6060 one negative value. This is true if and only if S is non-zero or S 6061 is zero and Card(B,H) is 2^32 or more.</p> 6062 <p>A (B,H,S) coding is <em>full-range</em> if Range(B,H,S) is 6063 <tt>[-2^31..2^31-1]</tt>.</p> 6064 <p>A sub-range coding delivers less than 2^31 distinct values. More 6065 precisely, a coding (B,H,S) is <em>sub-range</em> if Card(B,H,S) 6066 <= <tt>2^31-1</tt>. (Some codings are neither full-range nor 6067 sub-range codings.)</p> 6068 <p>As a consequence of these definitions, any coding for which 6069 B<=3 is a sub-range coding. Longer codings can also be 6070 sub-ranges if they are "sharp" enough. Some examples are (4,192,0), 6071 (5,32,0), and (5,32,1).</p> 6072 <p>Also, the unsigned coding (4,256,0) is full-range, as is the 6073 signed version (4,256,1), but not the doubly-signed version 6074 (4,256,2).</p> 6075 <p>The coding (4,255,0) is neither a sub-range nor a full-range 6076 coding, since its cardinality is 2^31. It represents only 6077 non-negative 32-bit integers, but its cardinality cannot be so 6078 represented.</p> 6079 <a name="tocEnCoSe" id="tocEnCoSe"></a> 6080 <h4>6.4. Encoding of Correlated Sequences</h4> 6081 Every single integer in the archive format is encoded according to 6082 some coding in the scheme of (B,H,S) codings. In addition, special 6083 attention is paid to sequences of integers (in the "bands" 6084 described elsewhere) which show statistical regularity. In 6085 particular, if a sequence of integers is found to exhibit a pattern 6086 of small, regular first-order differences, those differences may be 6087 encoded in place of the values themselves. This is described by a 6088 fourth coding parameter added to the (B,H,S) scheme. 6089 <table border="1" summary="encoding of correlated sequences"> 6090 <tr align="center"> 6091 <th id="corr_seq_enc_n">Name</th> 6092 <th id="corr_seq_enc_r">Range</th> 6093 <th id="corr_seq_enc_m">Meaning</th> 6094 </tr> 6095 <tr> 6096 <td headers="corr_seq_enc_n">B</td> 6097 <td headers="corr_seq_enc_r">[1..5]</td> 6098 <td headers="corr_seq_enc_m">maximum byte length</td> 6099 </tr> 6100 <tr> 6101 <td headers="corr_seq_enc_n">H</td> 6102 <td headers="corr_seq_enc_r">[1..256]</td> 6103 <td headers="corr_seq_enc_m">number of high byte values</td> 6104 </tr> 6105 <tr> 6106 <td headers="corr_seq_enc_n">L</td> 6107 <td headers="corr_seq_enc_r">[0..255]</td> 6108 <td headers="corr_seq_enc_m">number of low byte values, defined as 6109 (256-H)</td> 6110 </tr> 6111 <tr> 6112 <td headers="corr_seq_enc_n">S</td> 6113 <td headers="corr_seq_enc_r">[0..2]</td> 6114 <td headers="corr_seq_enc_m">number of sign bits</td> 6115 </tr> 6116 <tr> 6117 <td headers="corr_seq_enc_n">D</td> 6118 <td headers="corr_seq_enc_r">[0..1]</td> 6119 <td headers="corr_seq_enc_m">delta encoding order</td> 6120 </tr> 6121 </table> 6122 <p>If D is zero, no differencing is performed, and the (B,H,S,0) 6123 coding is in all ways identical to the corresponding (B,H,S) 6124 coding. If D is one, the values are encoded in terms of their 6125 successive differences.</p> 6126 <p>(Note: Sequences which are mostly monotonically ascending will 6127 often be favorably encoded using unsigned delta codings of the form 6128 (5,H,0,1).)</p> 6129 <p>Suppose a sequence of values X[i] is given, for some range of i 6130 in [0..N-1]. This sequence will be representable by a (B,H,S,1) 6131 coding only if the (B,H,S) coding is a sub-range or a full-range 6132 coding. (If it is neither, there is no legal (B,H,S,1) coding.)</p> 6133 <p>The sequence X[i] will be representable, only if there is a 6134 series of "delta values" D[i] whose partial sums 6135 <tt>Sum[j<=i](D[j])</tt> can represent the values X[i].</p> 6136 <p>Each (B,H,S,1) coding has a range, in which all X[i] values must 6137 lie. This range is defined as <tt>Range(B,H,S,1) = 6138 Range(B,H,0)</tt>. The range of a delta coding (B,H,S,1) contains 6139 negative numbers only if it is based on a full-range coding 6140 (B,H,S). Otherwise, the delta coding can only represent 6141 non-negative numbers. In practice, this is not a severe 6142 restriction, since in practice very few band elements are 6143 negative.</p> 6144 <p>The partial sums Sum[j<=i](D[j]) are allowed to leave the 6145 range, but the final X[i] values are always brought back into range 6146 by adding or subtracting a multiple of Card Range(B,H,0).</p> 6147 <p>More precisely:</p> 6148 <pre class="codeblock"> 6149 X[i] = Sum[j<=i](D[j]) mod Card(B,H,0) 6150 if (B,H,S) is sub-range 6151 X[i] = (int32) Sum[j<=i](D[j]) 6152 if (B,H,S) is full-range 6153 6154 </pre> 6155 (Here, the cast to <tt>int32</tt> denotes truncation to 32 bits.) 6156 <p>Note that implementations can simply ignore 32-bit wraparound 6157 when computing partial sums, if the coding is full-range. 6158 Otherwise, more care must be taken to bring partial sums back into 6159 range by subtracting or adding multiples of the range cardinality. 6160 Also, 32-bit wraparound may be a hazard for ranges of size 2^30 or 6161 more. It is possible to implement this using only 32-bit signed 6162 arithmetic.</p> 6163 <a name="tocEnUnVa" id="tocEnUnVa"></a> 6164 <h4>6.5. Encodings of Uncorrelated Values</h4> 6165 The coding methods described so far are designed to favor values 6166 which, on average, tend to be near zero or near the preceding 6167 value. Some data sets have marked statistical patterns in which 6168 values have only weak arithmetic relations (to zero or to each 6169 other), but which show strong repetitive patterns, especially in 6170 their first-order statistics. 6171 <p>The compressor may elect to use a population-based coding 6172 transformation in such cases. This transformation takes a sequence 6173 S of N arithmetic values and converts it into three value 6174 sequences:</p> 6175 <ul> 6176 <li>F a table (arbitrary length K+1 << N) of favored 6177 values</li> 6178 <li>T a sequence (length N) of value tokens</li> 6179 <li>U a sequence (length << N, depends on T) of unfavored 6180 values</li> 6181 </ul> 6182 <p>Each of these sequences (F, T, and U) is in turn treated as a 6183 sub-band, and transmitted with an independent encoding. Each 6184 non-zero value in T indexes a value from F, while each zero value 6185 in T selects (in order) a value from U:</p> 6186 <pre class="codeblock"> 6187 S[i] = F[T[i]-1] 6188 if T[i] != 0 6189 U = { S[i] such that T[i] == 0 } 6190 6191 </pre> 6192 <a name="tocTabFav" id="tocTabFav"></a> 6193 <h5>6.5.1. Table of Favorites</h5> 6194 The table F contains any number of integer values. There is no 6195 restriction on their number or identity, except that no value in F 6196 may be repeated, except the last, and F must not contain unused 6197 values. The last value in F must be a repetition of an earlier 6198 occurrence of a "sentinel value" of F. This sentinel marks the end 6199 of the table F, allowing the decompressor to prepare to read T and 6200 U. 6201 <p>The "central value" X of F is defined as that element of F which 6202 is arithmetically closest to zero. If F contains both a positive X 6203 and a negative -X of minimal absolute value, then -X is defined as 6204 the central value. (I.e., a negative sign is the tie-breaker. The 6205 central value is chosen so as to have a favorable encoding.)</p> 6206 <p>(Note that implementations may compare values for centrality by 6207 using the 32-bit signed int expression 6208 <code>(X>>31)^(X<<1)</code> as an unsigned comparison 6209 key.)</p> 6210 <p>A valid sentinel value is either the central value of F, or the 6211 last value of F. Thus, while parsing F, the decompressor must look 6212 for a repetition of either the central value (so far) or of the 6213 immediately previous value.</p> 6214 <p>Let K be the number of values in F, ignoring the repetition of 6215 the sentinel value. In the next band, values in <tt>[1..K]</tt> 6216 will refer (as 1-origin indexes) to corresponding elements of 6217 F.</p> 6218 <a name="tocSeqTok" id="tocSeqTok"></a> 6219 <h5>6.5.2. Sequence of Tokens</h5> 6220 The sequence T follows the table F, and encodes the input of the 6221 population transformation in a direct, element-by-element manner. 6222 <p>Each element of T is a token for either a favored or an 6223 unfavored value, encoded in the arithmetic range <tt>[0..K]</tt>. 6224 Each non-zero value corresponds in order to an element of F, and 6225 produces that favored value. Each zero value in T is a placeholder 6226 for an "unfavored" value, which is still unknown.</p> 6227 <p>As mentioned above, each element of F must be referred to by at 6228 least one element of T. That is, the following two sets must be the 6229 same:</p> 6230 <pre class="codeblock"> 6231 { F[T[i]-1] such that T[i] != 0 } 6232 { F[j] } 6233 6234 </pre> 6235 <p>The statistics of the sequence T are quite favorable for compact 6236 encoding in a suitable (B,H) scheme, assuming that the coder made 6237 good choices for the contents of F. Generally speaking, the most 6238 commonly occurring input values should be given early positions in 6239 F.</p> 6240 <p>A greedy algorithm could sort the input values by number of 6241 occurrences and place the most common values at the front of F. 6242 This would be likely to produce an improved encoding for the input. 6243 Such techniques are neither mandated nor discouraged by this 6244 specification.</p> 6245 <a name="tocSeUnVa" id="tocSeUnVa"></a> 6246 <h5>6.5.3. Sequence of Unfavored Values</h5> 6247 The third subsequence consists of values which were not 6248 representable by indexes into the table F. Let Z be the number of 6249 zeroes encountered in T. There is a ordered, one-to-one 6250 correspondence between the Z zeroes in T and all the Z values of U. 6251 <p>Taken together, the elements of F and U selected by the elements 6252 of T must be identical in value and order to the input of the 6253 population transformation.</p> 6254 <p>The decompressor can then read F into memory, read T into 6255 memory, and then make a second pass over T, translating token 6256 values, either referring to F or reading from U as necessary.</p> 6257 <a name="tocAdaEnc" id="tocAdaEnc"></a> 6258 <h4>6.6. Adaptive Encodings</h4> 6259 Sometimes, in a very long sequence of values, the statistics will 6260 change slowly, making an initially suitable coding tactic become 6261 unsuitable. 6262 <p>An adaptive coding method handles this situation by allowing 6263 value sequences to be partitioned (effectively into sub-bands), 6264 with an independent coding used locally in each part.</p> 6265 <p>An adaptive coding method is specified by a count K, a coding 6266 method A which will be used to encode K values, and another coding 6267 method B which will handle the rest of the values.</p> 6268 <p>Since bands are sized by context, when an adaptive coding method 6269 is applied to the bytes of an encoded band, the method will be 6270 provided in advance with the count N of values to decode. Thus, 6271 after the method A has decoded K values, the method B will be used 6272 to decode the rest of the (N-K) values in the band.</p> 6273 <a name="band_coding" id="band_coding"></a> <a name="tocMetCod" id= 6274 "tocMetCod"></a> 6275 <h4>6.7. Meta-Coding</h4> 6276 Every band in the Pack200 archive format whose primary encoding is 6277 not BYTE1 is optionally preceded by a series of bytes called a 6278 <em>band coding specifier</em> which specify a secondary coding or 6279 codings used in that band, instead of the primary coding. The 6280 decompressor must parse this coding specifier and save it away 6281 before it reads any of the band elements. In a few extra bytes of 6282 information, the coding specifier determines exactly how the 6283 subsequent bytes are to be decoded into band values. 6284 <p>Any compressor may elect not to provide a band coding specifier, 6285 in which case the band's primary encoding governs the transmission 6286 of elements. If the encoding of the first band element under the 6287 primary encoding accidentally appears to be a band coding 6288 specifier, the compressor is obligated to transmit an explicit band 6289 coding specifier that reaffirms the band's primary encoding. This 6290 is rare, because (as noted below) band coding specifiers present 6291 themselves as negative numbers in the primary encoding, and 6292 negative numbers are rare in most bands.</p> 6293 <a name="tocCoSpSt" id="tocCoSpSt"></a> 6294 <h5>6.7.1. Coding Specifier Structure</h5> 6295 The symbolic structure of a band coding specifier is determined by 6296 the following grammar. (This grammar is independent of the grammar 6297 governing band structure, or any other grammar appearing in other 6298 parts of this specification.) 6299 <pre class="codeblock"> 6300 BandCodingSpecifier: 6301 (Default | BHSDCode | RunCode | PopCode) 6302 BHSDCode: 6303 CanonicalBHSDCode | ArbitraryBHSDCode 6304 CanonicalBHSDCode: 6305 ( '(1,256,0)' | '(1,256,1)' | ... ) 6306 ArbitraryBHSDCode: 6307 'arb' ( B H S D ) 6308 B, H, S, D: 6309 Integer 6310 RunCode: 6311 'run' K ACode BCode 6312 K: 6313 Integer 6314 ACode: 6315 (Default | BHSDCode | PopCode) 6316 BCode: 6317 (Default | BHSDCode | RunCode | PopCode) 6318 PopCode: 6319 'pop' ( FCode TCode UCode ) 6320 FCode: 6321 (Default | BHSDCode | RunCode) 6322 TCode: 6323 (Default | BHSDCode | RunCode) 6324 UCode: 6325 (Default | BHSDCode | RunCode) 6326 Integer: 6327 ( '0' | '1' | ... ) 6328 Default: 6329 'default' 6330 6331 </pre> 6332 Note that adaptive coding methods ("RunCode" nonterminals) can be 6333 chained via the "BCode" nonterminal, but cannot be nested directly 6334 via the "ACode" nonterminal. (As the grammar shows, they may be 6335 nested indirectly via the "PopCode" nonterminal.) 6336 <p>Also, population coding methods can contain adaptive coding 6337 methods, and vice versa. However, although the grammar does not 6338 show this fact, population coding methods must not be nested, even 6339 indirectly.</p> 6340 <p>Not all possible integer values of K and L are equally well 6341 expressible. The intended values of K are commensurate with 6342 compressor windows, and the intended values of L are sharpness 6343 parameters for BHS encodings.</p> 6344 <a name="tocCoSpSe" id="tocCoSpSe"></a> 6345 <h5>6.7.2. Coding Specifier Semantics</h5> 6346 At any point, band contents are decoded under the control of three 6347 pieces of information: 6348 <ul> 6349 <li>N, an expected number of band values to decode, or 6350 "infinity"</li> 6351 <li>D, a default BHSD coding</li> 6352 <li>S, a coding specifier</li> 6353 </ul> 6354 <p>We denote the application of S in the context of N and D as 6355 "S(N,D)". This application decodes up to N elements of transmitted 6356 band data.</p> 6357 <p>Just before a band is received, the decompressor knows an 6358 expected band length N and a default coding method D, specified 6359 statically as the band's primary encoding. The decompressor then 6360 reads zero or more bytes which constitute a band encoding 6361 specifier, and decodes N elements of band data based on the band 6362 encoding specifier.</p> 6363 <p>When the coding specifier is 'default', N values are decoded 6364 using the default coding D, which is the band's primary encoding. 6365 (This rule is necessary if the band's first element appears to 6366 introduce a non-empty coding specifier. Such a default coding 6367 specifier is the only kind that a compressor is obligated to emit; 6368 the rest are all optional.)</p> 6369 <p>When the coding specifier is another BHSDCode, N values are 6370 decoded using that coding. The ambient default D is ignored.</p> 6371 <p>When the coding specifier is a 'run' of K, ACode, BCode, two 6372 steps are taken. First, the specifier ACode is given control, as 6373 ACode(K,D). That is, N is temporarily set to K. Second, the 6374 specifier BCode is given control as BCode(N-K,D). (Note: If N is 6375 infinity, N-K will also be infinity.) In both steps, D remains 6376 unchanged, so that occurrences of 'default' for ACode or BCode 6377 cause D to be used.</p> 6378 <p>It is illegal for a 'run' coding specifier to specify a K of 6379 zero, or for it to be used to decode a run of K or fewer 6380 values.</p> 6381 <p>When the coding specifier is a 'pop' of FCode, TCode, UCode, 6382 three steps are taken. First, FCode is applied as FCode(infinity, 6383 D). The decoding of the F values stops when the first duplicate 6384 value is encountered. (As specified in the section above on 6385 population coding, that duplicate value acts as a sentinel, and 6386 must be either the most "central" value read, or else the value 6387 immediately previous to the sentinel value.) Let K be the number of 6388 unique decoded values.</p> 6389 <p>During the decoding of the F values by FCode, every 'run' 6390 specifier in FCode must exhaust its count 'K' without decoding the 6391 sentinel value. That is, the sentinel must be decoded by the last 6392 simple BHSD coding in FCode.</p> 6393 <p>In the second step, a different coding TCode is used, since the 6394 T values are expected to be a dense encoding. TCode is applied as 6395 TCode(N,D), and the tokens are read which determine the band values 6396 to be delivered. (Note that a 'pop' coding method can only be 6397 applied if the N value supplied is finite. This will be true, since 6398 the only bands which are read with an infinite N are byte bands 6399 such as <tt>bc_codes</tt>.) Let Z be the number of zeroes decoded 6400 using TCode.</p> 6401 <p>The third step is to use UCode to decode Z values, using the 6402 original default encoding D. UCode is applied as U(Z,D). The 6403 resulting band is produced from the T sequence, as documented 6404 above, by replacing zeroes in the T sequence by successive U 6405 values, and replacing other elements of the T sequence by those 6406 indexed in the F sequence.</p> 6407 <p>It is illegal for a 'pop' coding specifier to be used to decode 6408 a run of no values, or of an infinite number of values. If Z (the 6409 number of unfavored values) is zero, it is illegal for UCode to be 6410 anything other than 'default'.</p> 6411 <a name="tocCoSpMeEn" id="tocCoSpMeEn"></a> 6412 <h5>6.7.3. Coding Specifier Meta-Encoding</h5> 6413 The compressor uses a tense, byte-oriented encoding to transmit the 6414 band encoding specifier. Although the "little language" above 6415 allows a wide range of encodings, in practice many of them are 6416 similar in performance and applicability. It is not necessary or 6417 desirable to allow the compressor complete freedom to specify any 6418 conceivable band encoding specifier. Instead, the meta-encoding 6419 described in this section allows the compressor to select from a 6420 limited but useful set of secondary encodings. It is up to the 6421 compressor to make a choice that improves compression; the 6422 heuristic or algorithm that controls such a selection is beyond the 6423 scope of this specification. 6424 <p>The common band coding specifier of 'default' is encoded in a 6425 way that often requires no extra bytes. If the band has no 6426 elements, no parsing at all is done. Otherwise, if the band's 6427 default encoding is of variable length, the decompressor is 6428 obligated to decode one value X from the initial bytes of the band 6429 using the band's default coding D. If possible, the value X is 6430 converted into an unsigned byte value XB, which is taken to be the 6431 first byte of a band coding specifier, and X will be discarded. 6432 Otherwise, the band coding specifier is taken to be 'default', and 6433 so D is applied to the entire band, including the bytes which 6434 produced the initial value X.</p> 6435 <p>D must be of the form (B,H,S) or (B,H,S,D), where B>1 and 6436 H<256. The value is D is irrelevant to the decoding of the first 6437 value, and the decoding of X is done using (B,H,S,0). If S is not 6438 zero, and if the value X is in the range [-256..-1], the coding 6439 specifier byte XB is defined as <tt>XB = (-1-X)</tt>, and X is 6440 discarded. Otherwise, if S is zero, and if the value of X is in the 6441 range [(256-H)..(511-H)], the coding specifier byte XB is defined 6442 as <tt>XB = (X-(256-H))</tt>, and X is discarded. Otherwise, there 6443 is not a coding specifier byte XB, and X is the first band value, 6444 as described above.</p> 6445 <p>The value XB, if produced, is taken to be the initial byte of a 6446 coding specifier preceding the actual band data. This specifier is 6447 parsed, starting with XB, and continuing (if necessary) with bytes 6448 bytes taken from <tt>band_headers</tt>. The parsed specifier is 6449 then used to control decoding, starting at the next byte, of all 6450 band elements.</p> 6451 <p>If the band really does start with an element X1 in a range 6452 (<tt>[-256..-1]</tt> or <tt>[L,L+255]</tt>) that requires the 6453 production of a band specififer byte XB, but the compressor wishes 6454 to use the default encoding, the compressor is required to specify 6455 a band header, lest X1 mislead the decompressor. If the compressor 6456 wishes to keep the default coding, it must in such cases specify an 6457 explicit coding specifier of 'default', using an XB value of zero 6458 (as specified below). This zero XB is transmitted, depending on the 6459 default encoding, as an X value of -1 (usually the byte 1) or of L 6460 (usually the bytes 192,0).</p> 6461 <p>(An immediate consequence of this design is that byte bands can 6462 never have non-default encodings, but all other bands can, since 6463 all the other bands have default encodigns which are variable 6464 length and have a large dynamic range. The "escape" values chosen 6465 for X are rare in practice, so they are not usually confused with 6466 real band data. Adding an extra zero value to reaffirm the default 6467 will always cost one extra byte before the actual band data, and no 6468 extra bytes in the <tt>band_headers</tt> band. In general, the 6469 encoding of explicit X values will always require two bytes if S is 6470 zero, and at most two bytes if S is not zero.)</p> 6471 <p>The band <tt>band_headers</tt> transmits the non-initial band 6472 header bytes (if any) of each band that has a band header. The 6473 order of transmission is consistent with the overall order of all 6474 bands in the archive, as given in the present specification's band 6475 grammar. The length of <tt>band_headers</tt> is independently 6476 specified (as <tt>#band_headers_size</tt>) in the archive header. 6477 (It should be clear that the decompressor needs to find the end of 6478 <tt>band_headers</tt> before it can read any further bands.)</p> 6479 <p>Thus, the encoding of a coding specifier consists of a sequence 6480 of bytes: an initial byte XB, and zero or more non-initial bytes 6481 taken from <tt>band_headers</tt>. The encodings of the little 6482 language specified in the previous section are as follows. The 6483 encoding 'default' is a zero byte. Of all the possible BHSDCode 6484 encodings, a sequence of 115 <em>canonical encodings</em> (defined 6485 below) is selected to cover the expected range of uses. A BHSDCode 6486 is represented as a single byte whose value is the index (1-based) 6487 of the selected canonical coding.</p> 6488 <pre class="codeblock"> 6489 Enc{default} = (0) 6490 Enc{CanonicalBHSDCode} = value in [1..115] 6491 6492 </pre> 6493 <p>The special value 116 introduces an arbitrary, possibly 6494 non-canonical BHSD code, described in the following byte.</p> 6495 <pre class="codeblock"> 6496 Enc{ arb ( B H S D ) } = 6497 116 6498 & (D:[0..1] + 2*S[0..2] + 8*(B:[1..5]-1)) 6499 & (H[1..256]-1): 6500 6501 </pre> 6502 The B value must be in the range [1..5]. The S value must be in the 6503 range [0..2]. The H value must be in the range [1..256]. The D 6504 value must be in the range [0..1]. (These ranges are inclusive.) In 6505 addition, if B is 1, H must be 256, and if H is 256, B must not be 6506 5. 6507 <p>The 'run' construct encodings begin with a byte in [117..140], 6508 and may be followed by an optional byte KB and then by one or two 6509 encoding specifiers ACode and BCode. The offset from 117 represents 6510 bitwise the following data:</p> 6511 <ul> 6512 <li>a two-bit field KX</li> 6513 <li>a bit KBFlag</li> 6514 <li>a bit ADef (ABDef == 1)</li> 6515 <li>a bit BDef (ABDef == 2)</li> 6516 </ul> 6517 The last two bits are jointly encoded in the value ABDef. They are 6518 never both true. 6519 <pre class="codeblock"> 6520 Enc{ run ( K ACode BCode ) } = 6521 (117 + (KX:[0..3]) + 4*(KBFlag:[0..1]) + 8*(ABDef:[0..2])) 6522 & KB: one of [0..255] if KBFlag=1 6523 & Enc{ ACode } if ADef=0 (ABDef != 1) 6524 & Enc{ BCode } if BDef=0 (ABDef != 2) 6525 6526 </pre> 6527 <p>After the leading byte is parsed, a byte KB is expected if the 6528 KBFlag is set, otherwise KB is implicitly given the value 3.</p> 6529 <p>The K value for the 'run' construct can take a range of values, 6530 and is determined as follows:</p> 6531 <pre class="codeblock"> 6532 K = (KB+1) * 16^KX 6533 6534 </pre> 6535 <p>The ACode coding is understood to be 'default' if the ADef bit 6536 is set. Otherwise, the representation of ACode is parsed next. 6537 Finally, the BCode coding is understood to be 'default' if the BDef 6538 bit is set. Otherwise, the representation of BCode is parsed last. 6539 Both ADef and BDef may be clear, but both may not be set.</p> 6540 <p>The 'pop' construct encodings begin with a byte in [141..188], 6541 and may be followed by one, two, or three encoding specifiers, 6542 FCode, UCode, and TCode. The offset from 141 bitwise encodes the 6543 following data:</p> 6544 <ul> 6545 <li>a bit FDef</li> 6546 <li>a bit UDef</li> 6547 <li>a bit TDef (TDefL > 0)</li> 6548 <li>a value L in [1..11] if TDef=1</li> 6549 </ul> 6550 The last two values are jointly encoded in the value TDefL. 6551 <pre class="codeblock"> 6552 Enc{ pop ( FCode TCode UCode ) } 6553 = (141 + (FDef:[0..1]) + 2*UDef:[0..1] + 4*(TDefL:[0..11])) 6554 & Enc{ FCode } if FDef=0 6555 & Enc{ TCode } if TDef=0 (TDefL==0) 6556 & Enc{ UCode } if UDef=0 6557 6558 </pre> 6559 <p>If TDef is zero, an explicit encoding specifier determines 6560 TCode, and the L parameter is not present. If TDef is one, the L 6561 parameter is present and is derived from TDefL, according to the 6562 following table:</p> 6563 <table border="1" summary="relation of L parameter to TDefL"> 6564 <tr align="center"> 6565 <th id="l_param_tdefl_t">TDefL</th> 6566 <th id="l_param_tdefl_l">L</th> 6567 </tr> 6568 <tr align="right"> 6569 <td headers="l_param_tdefl_t">1</td> 6570 <td headers="l_param_tdefl_l">4</td> 6571 </tr> 6572 <tr align="right"> 6573 <td headers="l_param_tdefl_t">2</td> 6574 <td headers="l_param_tdefl_l">8</td> 6575 </tr> 6576 <tr align="right"> 6577 <td headers="l_param_tdefl_t">3</td> 6578 <td headers="l_param_tdefl_l">16</td> 6579 </tr> 6580 <tr align="right"> 6581 <td headers="l_param_tdefl_t">4</td> 6582 <td headers="l_param_tdefl_l">32</td> 6583 </tr> 6584 <tr align="right"> 6585 <td headers="l_param_tdefl_t">5</td> 6586 <td headers="l_param_tdefl_l">64</td> 6587 </tr> 6588 <tr align="right"> 6589 <td headers="l_param_tdefl_t">6</td> 6590 <td headers="l_param_tdefl_l">128</td> 6591 </tr> 6592 <tr align="right"> 6593 <td headers="l_param_tdefl_t">7</td> 6594 <td headers="l_param_tdefl_l">192</td> 6595 </tr> 6596 <tr align="right"> 6597 <td headers="l_param_tdefl_t">8</td> 6598 <td headers="l_param_tdefl_l">224</td> 6599 </tr> 6600 <tr align="right"> 6601 <td headers="l_param_tdefl_t">9</td> 6602 <td headers="l_param_tdefl_l">240</td> 6603 </tr> 6604 <tr align="right"> 6605 <td headers="l_param_tdefl_t">10</td> 6606 <td headers="l_param_tdefl_l">248</td> 6607 </tr> 6608 <tr align="right"> 6609 <td headers="l_param_tdefl_t">11</td> 6610 <td headers="l_param_tdefl_l">252</td> 6611 </tr> 6612 </table> 6613 <p>If the L parameter is present, the TCode is derived from the K 6614 and L values. If K < 256, then TCode is BYTE1 (1,255,0), and L 6615 is ignored. Otherwise, TCode is the (B,H,S) coding where S=0, 6616 H=(256-L), and B is the smallest value such that [0..K] is 6617 contained in Range(B,H,S). (It is illegal to specify an L so large 6618 that Range(5,256-L,0) does not contain K.)</p> 6619 <p>The FCode coding is understood to be 'default' if the FDef bit 6620 is set. Otherwise, the representation of FCode is parsed 6621 immediately after the initial byte. The TCode coding is understood 6622 to be derived from K and L if the TDef bit is set. Otherwise, the 6623 representation of TCode is parsed next. Finally, the UCode coding 6624 is understood to be 'default' if the UDef bit is set. Otherwise, 6625 the representation of UCode is parsed last.</p> 6626 <a name="tocCanCod" id="tocCanCod"></a> 6627 <h5>6.7.4. Canonical BHSD Codings</h5> 6628 Here is the list of all the canonical BHSD codings. These codings 6629 are designed to match a diverse variety of band value ranges and 6630 statistics. 6631 <table border="1" summary="list of all canonical BHSD codings"> 6632 <tr> 6633 <th id="canon_bhsd_i">index</th> 6634 <th id="canon_bhsd_b">BHSD Coding</th> 6635 </tr> 6636 <tr> 6637 <td headers="canon_bhsd_i">1</td> 6638 <td headers="canon_bhsd_b">(1,256,0)</td> 6639 </tr> 6640 <tr> 6641 <td headers="canon_bhsd_i">2</td> 6642 <td headers="canon_bhsd_b">(1,256,1)</td> 6643 </tr> 6644 <tr> 6645 <td headers="canon_bhsd_i">3</td> 6646 <td headers="canon_bhsd_b">(1,256,0,1)</td> 6647 </tr> 6648 <tr> 6649 <td headers="canon_bhsd_i">4</td> 6650 <td headers="canon_bhsd_b">(1,256,1,1)</td> 6651 </tr> 6652 <tr> 6653 <td headers="canon_bhsd_i">5</td> 6654 <td headers="canon_bhsd_b">(2,256,0)</td> 6655 </tr> 6656 <tr> 6657 <td headers="canon_bhsd_i">6</td> 6658 <td headers="canon_bhsd_b">(2,256,1)</td> 6659 </tr> 6660 <tr> 6661 <td headers="canon_bhsd_i">7</td> 6662 <td headers="canon_bhsd_b">(2,256,0,1)</td> 6663 </tr> 6664 <tr> 6665 <td headers="canon_bhsd_i">8</td> 6666 <td headers="canon_bhsd_b">(2,256,1,1)</td> 6667 </tr> 6668 <tr> 6669 <td headers="canon_bhsd_i">9</td> 6670 <td headers="canon_bhsd_b">(3,256,0)</td> 6671 </tr> 6672 <tr> 6673 <td headers="canon_bhsd_i">10</td> 6674 <td headers="canon_bhsd_b">(3,256,1)</td> 6675 </tr> 6676 <tr> 6677 <td headers="canon_bhsd_i">11</td> 6678 <td headers="canon_bhsd_b">(3,256,0,1)</td> 6679 </tr> 6680 <tr> 6681 <td headers="canon_bhsd_i">12</td> 6682 <td headers="canon_bhsd_b">(3,256,1,1)</td> 6683 </tr> 6684 <tr> 6685 <td headers="canon_bhsd_i">13</td> 6686 <td headers="canon_bhsd_b">(4,256,0)</td> 6687 </tr> 6688 <tr> 6689 <td headers="canon_bhsd_i">14</td> 6690 <td headers="canon_bhsd_b">(4,256,1)</td> 6691 </tr> 6692 <tr> 6693 <td headers="canon_bhsd_i">15</td> 6694 <td headers="canon_bhsd_b">(4,256,0,1)</td> 6695 </tr> 6696 <tr> 6697 <td headers="canon_bhsd_i">16</td> 6698 <td headers="canon_bhsd_b">(4,256,1,1)</td> 6699 </tr> 6700 <tr> 6701 <td headers="canon_bhsd_i">17</td> 6702 <td headers="canon_bhsd_b">(5, 4,0)</td> 6703 </tr> 6704 <tr> 6705 <td headers="canon_bhsd_i">18</td> 6706 <td headers="canon_bhsd_b">(5, 4,1)</td> 6707 </tr> 6708 <tr> 6709 <td headers="canon_bhsd_i">19</td> 6710 <td headers="canon_bhsd_b">(5, 4,2)</td> 6711 </tr> 6712 <tr> 6713 <td headers="canon_bhsd_i">20</td> 6714 <td headers="canon_bhsd_b">(5, 16,0)</td> 6715 </tr> 6716 <tr> 6717 <td headers="canon_bhsd_i">21</td> 6718 <td headers="canon_bhsd_b">(5, 16,1)</td> 6719 </tr> 6720 <tr> 6721 <td headers="canon_bhsd_i">22</td> 6722 <td headers="canon_bhsd_b">(5, 16,2)</td> 6723 </tr> 6724 <tr> 6725 <td headers="canon_bhsd_i">23</td> 6726 <td headers="canon_bhsd_b">(5, 32,0)</td> 6727 </tr> 6728 <tr> 6729 <td headers="canon_bhsd_i">24</td> 6730 <td headers="canon_bhsd_b">(5, 32,1)</td> 6731 </tr> 6732 <tr> 6733 <td headers="canon_bhsd_i">25</td> 6734 <td headers="canon_bhsd_b">(5, 32,2)</td> 6735 </tr> 6736 <tr> 6737 <td headers="canon_bhsd_i">26</td> 6738 <td headers="canon_bhsd_b">(5, 64,0)</td> 6739 </tr> 6740 <tr> 6741 <td headers="canon_bhsd_i">27</td> 6742 <td headers="canon_bhsd_b">(5, 64,1)</td> 6743 </tr> 6744 <tr> 6745 <td headers="canon_bhsd_i">28</td> 6746 <td headers="canon_bhsd_b">(5, 64,2)</td> 6747 </tr> 6748 <tr> 6749 <td headers="canon_bhsd_i">29</td> 6750 <td headers="canon_bhsd_b">(5,128,0)</td> 6751 </tr> 6752 <tr> 6753 <td headers="canon_bhsd_i">30</td> 6754 <td headers="canon_bhsd_b">(5,128,1)</td> 6755 </tr> 6756 <tr> 6757 <td headers="canon_bhsd_i">31</td> 6758 <td headers="canon_bhsd_b">(5,128,2)</td> 6759 </tr> 6760 <tr> 6761 <td headers="canon_bhsd_i">32</td> 6762 <td headers="canon_bhsd_b">(5, 4,0,1)</td> 6763 </tr> 6764 <tr> 6765 <td headers="canon_bhsd_i">33</td> 6766 <td headers="canon_bhsd_b">(5, 4,1,1)</td> 6767 </tr> 6768 <tr> 6769 <td headers="canon_bhsd_i">34</td> 6770 <td headers="canon_bhsd_b">(5, 4,2,1)</td> 6771 </tr> 6772 <tr> 6773 <td headers="canon_bhsd_i">35</td> 6774 <td headers="canon_bhsd_b">(5, 16,0,1)</td> 6775 </tr> 6776 <tr> 6777 <td headers="canon_bhsd_i">36</td> 6778 <td headers="canon_bhsd_b">(5, 16,1,1)</td> 6779 </tr> 6780 <tr> 6781 <td headers="canon_bhsd_i">37</td> 6782 <td headers="canon_bhsd_b">(5, 16,2,1)</td> 6783 </tr> 6784 <tr> 6785 <td headers="canon_bhsd_i">38</td> 6786 <td headers="canon_bhsd_b">(5, 32,0,1)</td> 6787 </tr> 6788 <tr> 6789 <td headers="canon_bhsd_i">39</td> 6790 <td headers="canon_bhsd_b">(5, 32,1,1)</td> 6791 </tr> 6792 <tr> 6793 <td headers="canon_bhsd_i">40</td> 6794 <td headers="canon_bhsd_b">(5, 32,2,1)</td> 6795 </tr> 6796 <tr> 6797 <td headers="canon_bhsd_i">41</td> 6798 <td headers="canon_bhsd_b">(5, 64,0,1)</td> 6799 </tr> 6800 <tr> 6801 <td headers="canon_bhsd_i">42</td> 6802 <td headers="canon_bhsd_b">(5, 64,1,1)</td> 6803 </tr> 6804 <tr> 6805 <td headers="canon_bhsd_i">43</td> 6806 <td headers="canon_bhsd_b">(5, 64,2,1)</td> 6807 </tr> 6808 <tr> 6809 <td headers="canon_bhsd_i">44</td> 6810 <td headers="canon_bhsd_b">(5,128,0,1)</td> 6811 </tr> 6812 <tr> 6813 <td headers="canon_bhsd_i">45</td> 6814 <td headers="canon_bhsd_b">(5,128,1,1)</td> 6815 </tr> 6816 <tr> 6817 <td headers="canon_bhsd_i">46</td> 6818 <td headers="canon_bhsd_b">(5,128,2,1)</td> 6819 </tr> 6820 <tr> 6821 <td headers="canon_bhsd_i">47</td> 6822 <td headers="canon_bhsd_b">(2,192,0)</td> 6823 </tr> 6824 <tr> 6825 <td headers="canon_bhsd_i">48</td> 6826 <td headers="canon_bhsd_b">(2,224,0)</td> 6827 </tr> 6828 <tr> 6829 <td headers="canon_bhsd_i">49</td> 6830 <td headers="canon_bhsd_b">(2,240,0)</td> 6831 </tr> 6832 <tr> 6833 <td headers="canon_bhsd_i">50</td> 6834 <td headers="canon_bhsd_b">(2,248,0)</td> 6835 </tr> 6836 <tr> 6837 <td headers="canon_bhsd_i">51</td> 6838 <td headers="canon_bhsd_b">(2,252,0)</td> 6839 </tr> 6840 <tr> 6841 <td headers="canon_bhsd_i">52</td> 6842 <td headers="canon_bhsd_b">(2, 8,0,1)</td> 6843 </tr> 6844 <tr> 6845 <td headers="canon_bhsd_i">53</td> 6846 <td headers="canon_bhsd_b">(2, 8,1,1)</td> 6847 </tr> 6848 <tr> 6849 <td headers="canon_bhsd_i">54</td> 6850 <td headers="canon_bhsd_b">(2, 16,0,1)</td> 6851 </tr> 6852 <tr> 6853 <td headers="canon_bhsd_i">55</td> 6854 <td headers="canon_bhsd_b">(2, 16,1,1)</td> 6855 </tr> 6856 <tr> 6857 <td headers="canon_bhsd_i">56</td> 6858 <td headers="canon_bhsd_b">(2, 32,0,1)</td> 6859 </tr> 6860 <tr> 6861 <td headers="canon_bhsd_i">57</td> 6862 <td headers="canon_bhsd_b">(2, 32,1,1)</td> 6863 </tr> 6864 <tr> 6865 <td headers="canon_bhsd_i">58</td> 6866 <td headers="canon_bhsd_b">(2, 64,0,1)</td> 6867 </tr> 6868 <tr> 6869 <td headers="canon_bhsd_i">59</td> 6870 <td headers="canon_bhsd_b">(2, 64,1,1)</td> 6871 </tr> 6872 <tr> 6873 <td headers="canon_bhsd_i">60</td> 6874 <td headers="canon_bhsd_b">(2,128,0,1)</td> 6875 </tr> 6876 <tr> 6877 <td headers="canon_bhsd_i">61</td> 6878 <td headers="canon_bhsd_b">(2,128,1,1)</td> 6879 </tr> 6880 <tr> 6881 <td headers="canon_bhsd_i">62</td> 6882 <td headers="canon_bhsd_b">(2,192,0,1)</td> 6883 </tr> 6884 <tr> 6885 <td headers="canon_bhsd_i">63</td> 6886 <td headers="canon_bhsd_b">(2,192,1,1)</td> 6887 </tr> 6888 <tr> 6889 <td headers="canon_bhsd_i">64</td> 6890 <td headers="canon_bhsd_b">(2,224,0,1)</td> 6891 </tr> 6892 <tr> 6893 <td headers="canon_bhsd_i">65</td> 6894 <td headers="canon_bhsd_b">(2,224,1,1)</td> 6895 </tr> 6896 <tr> 6897 <td headers="canon_bhsd_i">66</td> 6898 <td headers="canon_bhsd_b">(2,240,0,1)</td> 6899 </tr> 6900 <tr> 6901 <td headers="canon_bhsd_i">67</td> 6902 <td headers="canon_bhsd_b">(2,240,1,1)</td> 6903 </tr> 6904 <tr> 6905 <td headers="canon_bhsd_i">68</td> 6906 <td headers="canon_bhsd_b">(2,248,0,1)</td> 6907 </tr> 6908 <tr> 6909 <td headers="canon_bhsd_i">69</td> 6910 <td headers="canon_bhsd_b">(2,248,1,1)</td> 6911 </tr> 6912 <tr> 6913 <td headers="canon_bhsd_i">70</td> 6914 <td headers="canon_bhsd_b">(3,192,0)</td> 6915 </tr> 6916 <tr> 6917 <td headers="canon_bhsd_i">71</td> 6918 <td headers="canon_bhsd_b">(3,224,0)</td> 6919 </tr> 6920 <tr> 6921 <td headers="canon_bhsd_i">72</td> 6922 <td headers="canon_bhsd_b">(3,240,0)</td> 6923 </tr> 6924 <tr> 6925 <td headers="canon_bhsd_i">73</td> 6926 <td headers="canon_bhsd_b">(3,248,0)</td> 6927 </tr> 6928 <tr> 6929 <td headers="canon_bhsd_i">74</td> 6930 <td headers="canon_bhsd_b">(3,252,0)</td> 6931 </tr> 6932 <tr> 6933 <td headers="canon_bhsd_i">75</td> 6934 <td headers="canon_bhsd_b">(3, 8,0,1)</td> 6935 </tr> 6936 <tr> 6937 <td headers="canon_bhsd_i">76</td> 6938 <td headers="canon_bhsd_b">(3, 8,1,1)</td> 6939 </tr> 6940 <tr> 6941 <td headers="canon_bhsd_i">77</td> 6942 <td headers="canon_bhsd_b">(3, 16,0,1)</td> 6943 </tr> 6944 <tr> 6945 <td headers="canon_bhsd_i">78</td> 6946 <td headers="canon_bhsd_b">(3, 16,1,1)</td> 6947 </tr> 6948 <tr> 6949 <td headers="canon_bhsd_i">79</td> 6950 <td headers="canon_bhsd_b">(3, 32,0,1)</td> 6951 </tr> 6952 <tr> 6953 <td headers="canon_bhsd_i">80</td> 6954 <td headers="canon_bhsd_b">(3, 32,1,1)</td> 6955 </tr> 6956 <tr> 6957 <td headers="canon_bhsd_i">81</td> 6958 <td headers="canon_bhsd_b">(3, 64,0,1)</td> 6959 </tr> 6960 <tr> 6961 <td headers="canon_bhsd_i">82</td> 6962 <td headers="canon_bhsd_b">(3, 64,1,1)</td> 6963 </tr> 6964 <tr> 6965 <td headers="canon_bhsd_i">83</td> 6966 <td headers="canon_bhsd_b">(3,128,0,1)</td> 6967 </tr> 6968 <tr> 6969 <td headers="canon_bhsd_i">84</td> 6970 <td headers="canon_bhsd_b">(3,128,1,1)</td> 6971 </tr> 6972 <tr> 6973 <td headers="canon_bhsd_i">85</td> 6974 <td headers="canon_bhsd_b">(3,192,0,1)</td> 6975 </tr> 6976 <tr> 6977 <td headers="canon_bhsd_i">86</td> 6978 <td headers="canon_bhsd_b">(3,192,1,1)</td> 6979 </tr> 6980 <tr> 6981 <td headers="canon_bhsd_i">87</td> 6982 <td headers="canon_bhsd_b">(3,224,0,1)</td> 6983 </tr> 6984 <tr> 6985 <td headers="canon_bhsd_i">88</td> 6986 <td headers="canon_bhsd_b">(3,224,1,1)</td> 6987 </tr> 6988 <tr> 6989 <td headers="canon_bhsd_i">89</td> 6990 <td headers="canon_bhsd_b">(3,240,0,1)</td> 6991 </tr> 6992 <tr> 6993 <td headers="canon_bhsd_i">90</td> 6994 <td headers="canon_bhsd_b">(3,240,1,1)</td> 6995 </tr> 6996 <tr> 6997 <td headers="canon_bhsd_i">91</td> 6998 <td headers="canon_bhsd_b">(3,248,0,1)</td> 6999 </tr> 7000 <tr> 7001 <td headers="canon_bhsd_i">92</td> 7002 <td headers="canon_bhsd_b">(3,248,1,1)</td> 7003 </tr> 7004 <tr> 7005 <td headers="canon_bhsd_i">93</td> 7006 <td headers="canon_bhsd_b">(4,192,0)</td> 7007 </tr> 7008 <tr> 7009 <td headers="canon_bhsd_i">94</td> 7010 <td headers="canon_bhsd_b">(4,224,0)</td> 7011 </tr> 7012 <tr> 7013 <td headers="canon_bhsd_i">95</td> 7014 <td headers="canon_bhsd_b">(4,240,0)</td> 7015 </tr> 7016 <tr> 7017 <td headers="canon_bhsd_i">96</td> 7018 <td headers="canon_bhsd_b">(4,248,0)</td> 7019 </tr> 7020 <tr> 7021 <td headers="canon_bhsd_i">97</td> 7022 <td headers="canon_bhsd_b">(4,252,0)</td> 7023 </tr> 7024 <tr> 7025 <td headers="canon_bhsd_i">98</td> 7026 <td headers="canon_bhsd_b">(4, 8,0,1)</td> 7027 </tr> 7028 <tr> 7029 <td headers="canon_bhsd_i">99</td> 7030 <td headers="canon_bhsd_b">(4, 8,1,1)</td> 7031 </tr> 7032 <tr> 7033 <td headers="canon_bhsd_i">100</td> 7034 <td headers="canon_bhsd_b">(4, 16,0,1)</td> 7035 </tr> 7036 <tr> 7037 <td headers="canon_bhsd_i">101</td> 7038 <td headers="canon_bhsd_b">(4, 16,1,1)</td> 7039 </tr> 7040 <tr> 7041 <td headers="canon_bhsd_i">102</td> 7042 <td headers="canon_bhsd_b">(4, 32,0,1)</td> 7043 </tr> 7044 <tr> 7045 <td headers="canon_bhsd_i">103</td> 7046 <td headers="canon_bhsd_b">(4, 32,1,1)</td> 7047 </tr> 7048 <tr> 7049 <td headers="canon_bhsd_i">104</td> 7050 <td headers="canon_bhsd_b">(4, 64,0,1)</td> 7051 </tr> 7052 <tr> 7053 <td headers="canon_bhsd_i">105</td> 7054 <td headers="canon_bhsd_b">(4, 64,1,1)</td> 7055 </tr> 7056 <tr> 7057 <td headers="canon_bhsd_i">106</td> 7058 <td headers="canon_bhsd_b">(4,128,0,1)</td> 7059 </tr> 7060 <tr> 7061 <td headers="canon_bhsd_i">107</td> 7062 <td headers="canon_bhsd_b">(4,128,1,1)</td> 7063 </tr> 7064 <tr> 7065 <td headers="canon_bhsd_i">108</td> 7066 <td headers="canon_bhsd_b">(4,192,0,1)</td> 7067 </tr> 7068 <tr> 7069 <td headers="canon_bhsd_i">109</td> 7070 <td headers="canon_bhsd_b">(4,192,1,1)</td> 7071 </tr> 7072 <tr> 7073 <td headers="canon_bhsd_i">110</td> 7074 <td headers="canon_bhsd_b">(4,224,0,1)</td> 7075 </tr> 7076 <tr> 7077 <td headers="canon_bhsd_i">111</td> 7078 <td headers="canon_bhsd_b">(4,224,1,1)</td> 7079 </tr> 7080 <tr> 7081 <td headers="canon_bhsd_i">112</td> 7082 <td headers="canon_bhsd_b">(4,240,0,1)</td> 7083 </tr> 7084 <tr> 7085 <td headers="canon_bhsd_i">113</td> 7086 <td headers="canon_bhsd_b">(4,240,1,1)</td> 7087 </tr> 7088 <tr> 7089 <td headers="canon_bhsd_i">114</td> 7090 <td headers="canon_bhsd_b">(4,248,0,1)</td> 7091 </tr> 7092 <tr> 7093 <td headers="canon_bhsd_i">115</td> 7094 <td headers="canon_bhsd_b">(4,248,1,1)</td> 7095 </tr> 7096 </table> 7097 <a name="tocStDeOu" id="tocStDeOu"></a> 7098 <h2>7. Stability of Decompressor Output</h2> 7099 From what has been said so far, it may appear that a decompressor 7100 has considerable free choice in its arrangement of class file 7101 contents. In the class file format, there are numerous degrees of 7102 freedom which have no effect on the meaning of the file. For 7103 example, constant pool entries, attribute lists, and class methods 7104 are presented in no significant order, and could be shuffled at 7105 will by the decompressor without changing the meaning of the Java 7106 application. 7107 <p>However, for any given Pack200 archive, every decompressor is 7108 required to produce a particular byte-wise image for each class 7109 file transmitted. This requirement is placed on decompressors in 7110 order to make it possible for compressors to transmit information, 7111 such as message digests, which relates to the eventual byte-wise 7112 contents of transmitted class files. This section describes the 7113 restrictions placed on every decompressor that makes the byte-wise 7114 contents of its output files a well-defined function of its 7115 input.</p> 7116 <p>In general, the order of elements in a decompressed class file 7117 must be consistent with the transmission order in the Pack200 7118 archive. For example, the order of a class's fields declared in the 7119 class file must correspond to the order in which that class's field 7120 descriptors were transmitted in the <tt>field_descr</tt> band. 7121 (This also happens to correspond to the order in the 7122 <tt>field_flags</tt> bands.) This table gives all of the required 7123 correspondences of class file order with archive transmission 7124 order:</p> 7125 <table border="1" summary= 7126 "required correspondences of class file order with archive transmission order"> 7127 <tr align="center"> 7128 <th id="archive_transmission_order_e">element in<br /> 7129 class file</th> 7130 <th id="archive_transmission_order_b">band which<br /> 7131 determines order</th> 7132 </tr> 7133 <tr> 7134 <td headers="archive_transmission_order_e">implemented 7135 interfaces</td> 7136 <td headers="archive_transmission_order_b">class_interface</td> 7137 </tr> 7138 <tr> 7139 <td headers="archive_transmission_order_e">declared fields</td> 7140 <td headers="archive_transmission_order_b">field_descr</td> 7141 </tr> 7142 <tr> 7143 <td headers="archive_transmission_order_e">declared methods</td> 7144 <td headers="archive_transmission_order_b">method_descr</td> 7145 </tr> 7146 <tr> 7147 <td headers="archive_transmission_order_e">code handler list</td> 7148 <td headers="archive_transmission_order_b"> 7149 code_handler_start_P</td> 7150 </tr> 7151 <tr> 7152 <td headers="archive_transmission_order_e">class attribute 7153 list</td> 7154 <td headers="archive_transmission_order_b">class_flags, 7155 class_attr_indexes</td> 7156 </tr> 7157 <tr> 7158 <td headers="archive_transmission_order_e">field attribute 7159 list</td> 7160 <td headers="archive_transmission_order_b">field_flags, 7161 field_attr_indexes</td> 7162 </tr> 7163 <tr> 7164 <td headers="archive_transmission_order_e">method attribute 7165 list</td> 7166 <td headers="archive_transmission_order_b">method_flags, 7167 method_attr_indexes</td> 7168 </tr> 7169 <tr> 7170 <td headers="archive_transmission_order_e">code attribute list</td> 7171 <td headers="archive_transmission_order_b">code_attr_indexes</td> 7172 </tr> 7173 <tr> 7174 <td headers="archive_transmission_order_e">constant pool 7175 entries</td> 7176 <td headers="archive_transmission_order_b">cp_Utf8, etc. (see 7177 below)</td> 7178 </tr> 7179 </table> 7180 <p>Together, these required correspondences of order determine the 7181 exact contents of the decompressed class file. The ordering of 7182 interfaces, fields, methods, and exception handlers is directly 7183 determined by the ordering of the bands that transmit them.</p> 7184 <a name="tocOrAtLi" id="tocOrAtLi"></a> 7185 <h3>7.1. Ordering of Attribute Lists</h3> 7186 Attribute lists for classes, fields, and methods must begin with 7187 all attributes transmitted because of set flag bits. The order must 7188 be index order (from LSB to MSB in the flag word). After any 7189 possible flag-caused attributes, the list must then contain any 7190 overflow attributes. Any attribute list with overflow attributes 7191 will present them in the same order as their layouts were 7192 transmitted in the corresponding series of values from 7193 <tt>class_attr_indexes</tt>, <tt>field_attr_indexes</tt>, 7194 <tt>method_attr_indexes</tt>, or <tt>code_attr_indexes</tt>. Note 7195 that an attribute layout whose index is less than 32 can be 7196 specified zero or one times via a flag bit. Independently, it can 7197 also be specified zero or more times via occurrences in a band 7198 transmitting overflow attribute layouts. 7199 <p>If an <tt>InnerClasses</tt> or <tt>BootstrapMethods</tt> 7200 attribute must be added to a class, under the rules given in the 7201 next section, those attributes must come last in the class's 7202 attribute list. If more than one such attribute is added, the 7203 relative ordering is <tt>BootstrapMethods</tt>, then 7204 <tt>InnerClasses</tt>.</p> 7205 <a name="ordering" id="ordering"></a> <a name="ic_subset_selection" 7206 id="ic_subset_selection"></a> <a name="tocOrCoPo" id= 7207 "tocOrCoPo"></a> 7208 <h3>7.2. Ordering of Constant Pools</h3> 7209 The constant pool <tt>cp(X)</tt> of a decompressed class file X is 7210 defined as if by a post-processing of X and <tt>cp_All</tt> after 7211 the decompressor has already produced most of X. Specifically, 7212 suppose that the contents of X are determined, except that: 7213 <ul> 7214 <li><tt>cp(X)</tt> is not yet defined,</li> 7215 <li>there is no <tt>InnerClasses</tt> attribute in X (even if was 7216 an <tt>ic_Local(X)</tt> transmitted), and</li> 7217 <li>the locations of constant references within X are noted but not 7218 initialized with numbers.</li> 7219 </ul> 7220 <p>Then <tt>cp(X)</tt> is defined as if by the following steps, 7221 which populate it from the global constant pool <tt>cp_All</tt>, 7222 and also potentially produce an <tt>InnerClasses</tt> attribute for 7223 X.</p> 7224 <ul> 7225 <li><tt>cp(X)</tt> is initially empty.</li> 7226 <li>Every constant referenced from X is added to 7227 <tt>cp(X)</tt>.</li> 7228 <li>In the next step, any constant from <tt>cp_Signature</tt> must 7229 be treated as making no additional references, despite its 7230 transmitted structure.</li> 7231 <li>Every constant referenced from <tt>cp(X)</tt> is added to 7232 <tt>cp(X)</tt>, if it is not already there. (For example, a 7233 constant from <tt>cp_Method</tt> refers to constants from 7234 <tt>cp_Class</tt> and <tt>cp_Descr</tt>.)</li> 7235 <li>The previous step is iterated until no further changes occur. 7236 (There will be at most five more of these steps, with a longest 7237 chain of references consisting, for example, of a 7238 <tt>CONSTANT_InvokeDynamic</tt>, its <tt>cp_BootstrapMethod</tt> 7239 constant, a <tt>CONSTANT_MethodHandle</tt>, a 7240 <tt>CONSTANT_Methodref</tt>, a <tt>CONSTANT_NameAndType</tt>, and a 7241 <tt>CONSTANT_Utf8</tt>.)</li> 7242 </ul> 7243 <p>At this point the constant pool <tt>cp(X)</tt> is well enough 7244 defined to allow the decompressor to compute the set of relevant 7245 nested classes, called <tt>ic_Relevant(X)</tt>.</p> 7246 <ul> 7247 <li><tt>ic_Relevant(X)</tt> is initially empty.</li> 7248 <li>Every four-tuple from <tt>ic_All</tt> which mentions the 7249 current class (defined by X) as an outer class is added to 7250 <tt>ic_Relevant(X)</tt>.</li> 7251 <li>For every class constant K referenced from both 7252 <tt>ic_this_class</tt> and <tt>cp(X)</tt>, the corresponding 7253 four-tuple from <tt>ic_All</tt> is selected, and added to 7254 <tt>ic_Relevant(X)</tt>, if not already there.</li> 7255 <li>The previous step is repeated until closure. (That is, until 7256 <tt>ic_Relevant(X)</tt> no longer changes.)</li> 7257 <li>The set <tt>ic_Relevant(X)</tt> is ordered into a sequence, so 7258 that its order is consistent with <tt>ic_All</tt>. (I.e., it is a 7259 subsequence of <tt>ic_All</tt>.)</li> 7260 </ul> 7261 <p>With <tt>ic_Relevant(X)</tt> and an optionally transmitted 7262 <tt>ic_Local(X)</tt> in hand, the decompressor must next decide 7263 whether to store an <tt>InnerClasses</tt> attribute 7264 <tt>ic_Stored(X)</tt> for X, using these steps.</p> 7265 <ul> 7266 <li>If <tt>ic_Local(X)</tt> is present and empty, no 7267 <tt>InnerClasses</tt> attribute will be stored for X, and none of 7268 the following steps will be taken.</li> 7269 <li>Also, if <tt>ic_Local(X)</tt> is not present and 7270 <tt>ic_Relevant(X)</tt> is empty, no <tt>InnerClasses</tt> 7271 attribute will be stored for X.</li> 7272 <li>Otherwise, <tt>ic_Stored(X)</tt> is set to be the elements in 7273 <tt>ic_Local(X)</tt> followed by the elements of 7274 <tt>ic_Relevant(X)</tt> (both in transmission order).</li> 7275 <li>Next, any elements in both <tt>ic_Local(X)</tt> and 7276 <tt>ic_Relevant(X)</tt> are <em>removed</em> from 7277 <tt>ic_Stored(X)</tt>, thus forming a symmetric difference.</li> 7278 <li>The resulting sequence <tt>ic_Stored(X)</tt>, even if empty, is 7279 added to the decompressor's output as an <tt>InnerClasses</tt> 7280 attribute.</li> 7281 <li>All <tt>cp_Class</tt> and <tt>cp_Utf8</tt> entries directly or 7282 indirectly required by <tt>ic_Stored(X)</tt>, as well as the fixed 7283 <tt>cp_Utf8</tt> entry spelled <tt>"InnerClasses"</tt>, are added 7284 to <tt>cp(X)</tt> if not already there.</li> 7285 </ul> 7286 <p>With the last contributions from nested class records, the 7287 decompressor finishes the constant pool using these steps:</p> 7288 <ul> 7289 <li>Every <tt>cp_Signature</tt> entry in <tt>cp(X)</tt> is 7290 "flattened" into a <tt>cp_Utf8</tt> entry with the same 7291 spelling.</li> 7292 <li>If any <tt>cp_Utf8</tt> entry E in <tt>cp(X)</tt> was not 7293 transmitted in <tt>cp_All</tt> but had an equivalently spelled 7294 signature S transmitted, then E is replaced by S in 7295 <tt>cp(X)</tt>.</li> 7296 <li>The elements of <tt>cp(X)</tt> which are also in 7297 <tt>cp_All</tt> are sorted into the same order as their occurrences 7298 in <tt>cp_All</tt>.</li> 7299 <li>All <tt>cp_Utf8</tt> constants in <tt>cp(X)</tt> not also in 7300 <tt>cp_All</tt> are moved to the end of <tt>cp(X)</tt>, and are 7301 sorted in the order defined by <tt>String.compareTo</tt>.</li> 7302 <li>Next, any <tt>cp_Class</tt> constants in <tt>cp(X)</tt> not 7303 also in <tt>cp_All</tt> are moved to the end of <tt>cp(X)</tt>, in 7304 the order defined by <tt>String.compareTo</tt> on their class 7305 names.</li> 7306 <li>(At this point, the decompressor has uniquely determined a 7307 position for every element of <tt>cp(X)</tt>.)</li> 7308 <li>All elements of <tt>cp(X)</tt> which are referred to via a 7309 one-byte index (i.e., a ldc bytecode) are moved in mass to the 7310 beginning of <tt>cp(X)</tt>, without changing their relative 7311 order.</li> 7312 <li>All elements of <tt>cp(X)</tt> are transformed into their 7313 equivalent class file constant types, with signatures being 7314 "flattened" into equivalently spelled CONSTANT_Utf8 constants.</li> 7315 <li>All <tt>cp_BootstrapMethod</tt> constants in <tt>cp(X)</tt> are 7316 removed from <tt>cp(X)</tt> and placed (without reordering) in the 7317 <tt>BootstrapMethods</tt> attribute for X. (If there are no such 7318 elements, no such attribute is created.) If the attribute is 7319 created, <tt>cp_Utf8</tt> entry spelled <tt>"BootstrapMethods"</tt> is added 7320 to <tt>cp(X)</tt> if not already there.</li> 7321 <li>The resulting sequence of class file constants, <tt>cp(X)</tt>, 7322 is stored as the constant pool of X.</li> 7323 </ul> 7324 <p>After this process, the stored constant pool of X has 7325 referential integrity, and all constant references can be coded as 7326 indexes into <tt>cp(X)</tt>, which has a definite order derived 7327 from <tt>cp_All</tt>. In particular, if a constant in 7328 <tt>cp(X)</tt> needs to refer to another constant, that constant 7329 must already have been inserted into <tt>cp(X)</tt>, during the 7330 closure steps.</p> 7331 <p>Note that the ordering of <tt>cp(X)</tt> is consistent with that 7332 of <tt>cp_All</tt>, except that some signature references are 7333 redirected to equivalent pre-existing elements of <tt>cp_Utf8</tt>, 7334 and all operands of ldc bytecodes are forced to the front of the 7335 constant pool.</p> 7336 <p>When assigning local indexes to elements of <tt>cp(X)</tt>, the 7337 decompressor must of course respect the reservation of empty 7338 constant pool slots for index zero, and for CONSTANT_Long and 7339 CONSTANT_Double constants, as required by the class file format. 7340 Together with these rules, the construction and ordering of 7341 <tt>cp(X)</tt> completely determines the assignment of concrete 7342 indexes to constant references within X.</p> 7343 <a name="tocAppend" id="tocAppend"></a> 7344 <h2>8. Appendixes</h2> 7345 <a name="bands" id="bands"></a> <a name="tocApLiBa" id= 7346 "tocApLiBa"></a> 7347 <h3>8.1. Appendix: List of Bands</h3> 7348 Here is a list of all bands in the order they must occur in the 7349 archive. This list is not part of the Pack200 specification, but it 7350 is presented to help clarify the meaning of the grammar in the 7351 specification proper which defines the names and ordering of the 7352 bands. Four occurrences of ellipsis <strong>...</strong> refer to 7353 insertion points where the compressor may insert variable numbers 7354 of extra bands to help transmit unusual strings or non-standard 7355 attributes. The other ellipses refer to repetitions of metadata 7356 bands which it would be too tedious to include. 7357 <table border="1" summary="list of all bands"> 7358 <tr align="center"> 7359 <th id="list_of_all_bands_b">Band</th> 7360 <th id="list_of_all_bands_d">Default<br /> 7361 coding</th> 7362 <th id="list_of_all_bands_l">Length</th> 7363 <th id="list_of_all_bands_c">Constant pool<br /> 7364 referred to</th> 7365 </tr> 7366 <tr> 7367 <td headers="list_of_all_bands_b"><tt>archive_magic</tt></td> 7368 <td headers="list_of_all_bands_d">BYTE1</td> 7369 <td headers="list_of_all_bands_l"><tt>[4]</tt></td> 7370 <td headers="list_of_all_bands_c"> </td> 7371 </tr> 7372 <tr> 7373 <td headers="list_of_all_bands_b"><tt>archive_header</tt></td> 7374 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7375 <td headers="list_of_all_bands_l"><tt>[26]</tt></td> 7376 <td headers="list_of_all_bands_c"> </td> 7377 </tr> 7378 <tr> 7379 <td headers="list_of_all_bands_b"><tt>band_headers</tt></td> 7380 <td headers="list_of_all_bands_d">BYTE1</td> 7381 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7382 <td headers="list_of_all_bands_c"> </td> 7383 </tr> 7384 <tr> 7385 <td headers="list_of_all_bands_b"><tt>cp_Utf8_prefix</tt></td> 7386 <td headers="list_of_all_bands_d">DELTA5</td> 7387 <td headers="list_of_all_bands_l"> 7388 <tt>[MAX(0,#cp_Utf8_count-2)]</tt></td> 7389 <td headers="list_of_all_bands_c"> </td> 7390 </tr> 7391 <tr> 7392 <td headers="list_of_all_bands_b"><tt>cp_Utf8_suffix</tt></td> 7393 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7394 <td headers="list_of_all_bands_l"> 7395 <tt>[MAX(0,#cp_Utf8_count-1)]</tt></td> 7396 <td headers="list_of_all_bands_c"> </td> 7397 </tr> 7398 <tr> 7399 <td headers="list_of_all_bands_b"><tt>cp_Utf8_chars</tt></td> 7400 <td headers="list_of_all_bands_d">CHAR3</td> 7401 <td headers="list_of_all_bands_l"> 7402 <tt>[SUM(*cp_Utf8_suffix)]</tt></td> 7403 <td headers="list_of_all_bands_c"> </td> 7404 </tr> 7405 <tr> 7406 <td headers="list_of_all_bands_b"><tt>cp_Utf8_big_suffix</tt></td> 7407 <td headers="list_of_all_bands_d">DELTA5</td> 7408 <td headers="list_of_all_bands_l"> 7409 <tt>[COUNT(0,*cp_Utf8_suffix)]</tt></td> 7410 <td headers="list_of_all_bands_c"> </td> 7411 </tr> 7412 <tr> 7413 <td headers="list_of_all_bands_b"> 7414 <tt>{cp_Utf8_big_chars...}</tt></td> 7415 <td headers="list_of_all_bands_d">DELTA5</td> 7416 <td headers="list_of_all_bands_l"> 7417 <tt>[*cp_Utf8_big_suffix[i]]</tt></td> 7418 <td headers="list_of_all_bands_c"> </td> 7419 </tr> 7420 <tr> 7421 <td headers="list_of_all_bands_b"><tt>cp_Int</tt></td> 7422 <td headers="list_of_all_bands_d">UDELTA5</td> 7423 <td headers="list_of_all_bands_l"><tt>[#cp_Int_count]</tt></td> 7424 <td headers="list_of_all_bands_c"> </td> 7425 </tr> 7426 <tr> 7427 <td headers="list_of_all_bands_b"><tt>cp_Float</tt></td> 7428 <td headers="list_of_all_bands_d">UDELTA5</td> 7429 <td headers="list_of_all_bands_l"><tt>[#cp_Float_count]</tt></td> 7430 <td headers="list_of_all_bands_c"> </td> 7431 </tr> 7432 <tr> 7433 <td headers="list_of_all_bands_b"><tt>cp_Long_hi</tt></td> 7434 <td headers="list_of_all_bands_d">UDELTA5</td> 7435 <td headers="list_of_all_bands_l"><tt>[#cp_Long_count]</tt></td> 7436 <td headers="list_of_all_bands_c"> </td> 7437 </tr> 7438 <tr> 7439 <td headers="list_of_all_bands_b"><tt>cp_Long_lo</tt></td> 7440 <td headers="list_of_all_bands_d">DELTA5</td> 7441 <td headers="list_of_all_bands_l"><tt>[#cp_Long_count]</tt></td> 7442 <td headers="list_of_all_bands_c"> </td> 7443 </tr> 7444 <tr> 7445 <td headers="list_of_all_bands_b"><tt>cp_Double_hi</tt></td> 7446 <td headers="list_of_all_bands_d">UDELTA5</td> 7447 <td headers="list_of_all_bands_l"><tt>[#cp_Double_count]</tt></td> 7448 <td headers="list_of_all_bands_c"> </td> 7449 </tr> 7450 <tr> 7451 <td headers="list_of_all_bands_b"><tt>cp_Double_lo</tt></td> 7452 <td headers="list_of_all_bands_d">DELTA5</td> 7453 <td headers="list_of_all_bands_l"><tt>[#cp_Double_count]</tt></td> 7454 <td headers="list_of_all_bands_c"> </td> 7455 </tr> 7456 <tr> 7457 <td headers="list_of_all_bands_b"><tt>cp_String</tt></td> 7458 <td headers="list_of_all_bands_d">UDELTA5</td> 7459 <td headers="list_of_all_bands_l"><tt>[#cp_String_count]</tt></td> 7460 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7461 </tr> 7462 <tr> 7463 <td headers="list_of_all_bands_b"><tt>cp_Class</tt></td> 7464 <td headers="list_of_all_bands_d">UDELTA5</td> 7465 <td headers="list_of_all_bands_l"><tt>[#cp_Class_count]</tt></td> 7466 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7467 </tr> 7468 <tr> 7469 <td headers="list_of_all_bands_b"><tt>cp_Signature_form</tt></td> 7470 <td headers="list_of_all_bands_d">DELTA5</td> 7471 <td headers="list_of_all_bands_l"> 7472 <tt>[#cp_Signature_count]</tt></td> 7473 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7474 </tr> 7475 <tr> 7476 <td headers="list_of_all_bands_b"> 7477 <tt>cp_Signature_classes</tt></td> 7478 <td headers="list_of_all_bands_d">UDELTA5</td> 7479 <td headers="list_of_all_bands_l"><tt>[COUNT('L',...)]</tt></td> 7480 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7481 </tr> 7482 <tr> 7483 <td headers="list_of_all_bands_b"><tt>cp_Descr_name</tt></td> 7484 <td headers="list_of_all_bands_d">DELTA5</td> 7485 <td headers="list_of_all_bands_l"><tt>[#cp_Descr_count]</tt></td> 7486 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7487 </tr> 7488 <tr> 7489 <td headers="list_of_all_bands_b"><tt>cp_Descr_type</tt></td> 7490 <td headers="list_of_all_bands_d">UDELTA5</td> 7491 <td headers="list_of_all_bands_l"><tt>[#cp_Descr_count]</tt></td> 7492 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7493 </tr> 7494 <tr> 7495 <td headers="list_of_all_bands_b"><tt>cp_Field_class</tt></td> 7496 <td headers="list_of_all_bands_d">DELTA5</td> 7497 <td headers="list_of_all_bands_l"><tt>[#cp_Field_count]</tt></td> 7498 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7499 </tr> 7500 <tr> 7501 <td headers="list_of_all_bands_b"><tt>cp_Field_desc</tt></td> 7502 <td headers="list_of_all_bands_d">UDELTA5</td> 7503 <td headers="list_of_all_bands_l"><tt>[#cp_Field_count]</tt></td> 7504 <td headers="list_of_all_bands_c"><tt>cp_Descr</tt></td> 7505 </tr> 7506 <tr> 7507 <td headers="list_of_all_bands_b"><tt>cp_Method_class</tt></td> 7508 <td headers="list_of_all_bands_d">DELTA5</td> 7509 <td headers="list_of_all_bands_l"><tt>[#cp_Method_count]</tt></td> 7510 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7511 </tr> 7512 <tr> 7513 <td headers="list_of_all_bands_b"><tt>cp_Method_desc</tt></td> 7514 <td headers="list_of_all_bands_d">UDELTA5</td> 7515 <td headers="list_of_all_bands_l"><tt>[#cp_Method_count]</tt></td> 7516 <td headers="list_of_all_bands_c"><tt>cp_Descr</tt></td> 7517 </tr> 7518 <tr> 7519 <td headers="list_of_all_bands_b"><tt>cp_Imethod_class</tt></td> 7520 <td headers="list_of_all_bands_d">DELTA5</td> 7521 <td headers="list_of_all_bands_l"><tt>[#cp_Imethod_count]</tt></td> 7522 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7523 </tr> 7524 <tr> 7525 <td headers="list_of_all_bands_b"><tt>cp_Imethod_desc</tt></td> 7526 <td headers="list_of_all_bands_d">UDELTA5</td> 7527 <td headers="list_of_all_bands_l"><tt>[#cp_Imethod_count]</tt></td> 7528 <td headers="list_of_all_bands_c"><tt>cp_Descr</tt></td> 7529 </tr> 7530 <tr> 7531 <td headers="list_of_all_bands_b"> 7532 <tt>cp_MethodHandle_refkind</tt></td> 7533 <td headers="list_of_all_bands_d">DELTA5</td> 7534 <td headers="list_of_all_bands_l"> 7535 <tt>[#cp_MethodHandle_count]</tt></td> 7536 <td headers="list_of_all_bands_c"> </td> 7537 </tr> 7538 <tr> 7539 <td headers="list_of_all_bands_b"> 7540 <tt>cp_MethodHandle_member</tt></td> 7541 <td headers="list_of_all_bands_d">UDELTA5</td> 7542 <td headers="list_of_all_bands_l"> 7543 <tt>[#cp_MethodHandle_count]</tt></td> 7544 <td headers="list_of_all_bands_c"><tt>cp_All</tt></td> 7545 </tr> 7546 <tr> 7547 <td headers="list_of_all_bands_b"><tt>cp_MethodType</tt></td> 7548 <td headers="list_of_all_bands_d">UDELTA5</td> 7549 <td headers="list_of_all_bands_l"> 7550 <tt>[#cp_MethodType_count]</tt></td> 7551 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7552 <td headers="list_of_all_bands_c"> </td> 7553 </tr> 7554 <tr> 7555 <td headers="list_of_all_bands_b"> 7556 <tt>cp_BootstrapMethod_ref</tt></td> 7557 <td headers="list_of_all_bands_d">DELTA5</td> 7558 <td headers="list_of_all_bands_l"> 7559 <tt>[#cp_BootstrapMethod_count]</tt></td> 7560 <td headers="list_of_all_bands_c"><tt>cp_MethodHandle</tt></td> 7561 </tr> 7562 <tr> 7563 <td headers="list_of_all_bands_b"> 7564 <tt>cp_BootstrapMethod_arg_count</tt></td> 7565 <td headers="list_of_all_bands_d">UDELTA5</td> 7566 <td headers="list_of_all_bands_l"> 7567 <tt>[#cp_BootstrapMethod_count]arg_tt></tt></td> 7568 <td headers="list_of_all_bands_c"> </td> 7569 </tr> 7570 <tr> 7571 <td headers="list_of_all_bands_b"> 7572 <tt>cp_BootstrapMethod_arg</tt></td> 7573 <td headers="list_of_all_bands_d">DELTA5</td> 7574 <td headers="list_of_all_bands_l"> 7575 <tt>[SUM(*class_interface_count)]</tt></td> 7576 <td headers="list_of_all_bands_c"><tt>cp_All</tt></td> 7577 </tr> 7578 <tr> 7579 <td headers="list_of_all_bands_b"> 7580 <tt>cp_InvokeDynamic_spec</tt></td> 7581 <td headers="list_of_all_bands_d">DELTA5</td> 7582 <td headers="list_of_all_bands_l"> 7583 <tt>[#cp_InvokeDynamic_count]</tt></td> 7584 <td headers="list_of_all_bands_c"><tt>cp_BootstrapMethod</tt></td> 7585 </tr> 7586 <tr> 7587 <td headers="list_of_all_bands_b"> 7588 <tt>cp_InvokeDynamic_descr</tt></td> 7589 <td headers="list_of_all_bands_d">UDELTA5</td> 7590 <td headers="list_of_all_bands_l"> 7591 <tt>[#cp_InvokeDynamic_count]</tt></td> 7592 <td headers="list_of_all_bands_c"><tt>cp_Descr</tt></td> 7593 </tr> 7594 <tr> 7595 <td headers="list_of_all_bands_b"> 7596 <tt>attr_definition_headers</tt></td> 7597 <td headers="list_of_all_bands_d">BYTE1</td> 7598 <td headers="list_of_all_bands_l"> 7599 <tt>[#attr_definition_count]</tt></td> 7600 <td headers="list_of_all_bands_c"> </td> 7601 </tr> 7602 <tr> 7603 <td headers="list_of_all_bands_b"> 7604 <tt>attr_definition_name</tt></td> 7605 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7606 <td headers="list_of_all_bands_l"> 7607 <tt>[#attr_definition_count]</tt></td> 7608 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7609 </tr> 7610 <tr> 7611 <td headers="list_of_all_bands_b"> 7612 <tt>attr_definition_layout</tt></td> 7613 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7614 <td headers="list_of_all_bands_l"> 7615 <tt>[#attr_definition_count]</tt></td> 7616 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7617 </tr> 7618 <tr> 7619 <td headers="list_of_all_bands_b"><tt>ic_this_class</tt></td> 7620 <td headers="list_of_all_bands_d">UDELTA5</td> 7621 <td headers="list_of_all_bands_l"><tt>[#ic_count]</tt></td> 7622 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7623 </tr> 7624 <tr> 7625 <td headers="list_of_all_bands_b"><tt>ic_flags</tt></td> 7626 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7627 <td headers="list_of_all_bands_l"><tt>[#ic_count]</tt></td> 7628 <td headers="list_of_all_bands_c"> </td> 7629 </tr> 7630 <tr> 7631 <td headers="list_of_all_bands_b"><tt>ic_outer_class</tt></td> 7632 <td headers="list_of_all_bands_d">DELTA5</td> 7633 <td headers="list_of_all_bands_l"> 7634 <tt>[COUNT(1<<16,...)]</tt></td> 7635 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7636 </tr> 7637 <tr> 7638 <td headers="list_of_all_bands_b"><tt>ic_name</tt></td> 7639 <td headers="list_of_all_bands_d">DELTA5</td> 7640 <td headers="list_of_all_bands_l"> 7641 <tt>[COUNT(1<<16,...)]</tt></td> 7642 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7643 </tr> 7644 <tr> 7645 <td headers="list_of_all_bands_b"><tt>class_this</tt></td> 7646 <td headers="list_of_all_bands_d">DELTA5</td> 7647 <td headers="list_of_all_bands_l"><tt>[#class_count]</tt></td> 7648 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7649 </tr> 7650 <tr> 7651 <td headers="list_of_all_bands_b"><tt>class_super</tt></td> 7652 <td headers="list_of_all_bands_d">DELTA5</td> 7653 <td headers="list_of_all_bands_l"><tt>[#class_count]</tt></td> 7654 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7655 </tr> 7656 <tr> 7657 <td headers="list_of_all_bands_b"> 7658 <tt>class_interface_count</tt></td> 7659 <td headers="list_of_all_bands_d">DELTA5</td> 7660 <td headers="list_of_all_bands_l"><tt>[#class_count]</tt></td> 7661 <td headers="list_of_all_bands_c"> </td> 7662 </tr> 7663 <tr> 7664 <td headers="list_of_all_bands_b"><tt>class_interface</tt></td> 7665 <td headers="list_of_all_bands_d">DELTA5</td> 7666 <td headers="list_of_all_bands_l"> 7667 <tt>[SUM(*class_interface_count)]</tt></td> 7668 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7669 </tr> 7670 <tr> 7671 <td headers="list_of_all_bands_b"><tt>class_field_count</tt></td> 7672 <td headers="list_of_all_bands_d">DELTA5</td> 7673 <td headers="list_of_all_bands_l"><tt>[#class_count]</tt></td> 7674 <td headers="list_of_all_bands_c"> </td> 7675 </tr> 7676 <tr> 7677 <td headers="list_of_all_bands_b"><tt>class_method_count</tt></td> 7678 <td headers="list_of_all_bands_d">DELTA5</td> 7679 <td headers="list_of_all_bands_l"><tt>[#class_count]</tt></td> 7680 <td headers="list_of_all_bands_c"> </td> 7681 </tr> 7682 <tr> 7683 <td headers="list_of_all_bands_b"><tt>field_descr</tt></td> 7684 <td headers="list_of_all_bands_d">DELTA5</td> 7685 <td headers="list_of_all_bands_l"> 7686 <tt>[SUM(*class_field_count)]</tt></td> 7687 <td headers="list_of_all_bands_c"><tt>cp_Descr</tt></td> 7688 </tr> 7689 <tr> 7690 <td headers="list_of_all_bands_b"><tt>field_flags_hi</tt></td> 7691 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7692 <td headers="list_of_all_bands_l"> 7693 <tt>[SUM(*class_field_count)*#have_field_flags_hi]</tt></td> 7694 <td headers="list_of_all_bands_c"> </td> 7695 </tr> 7696 <tr> 7697 <td headers="list_of_all_bands_b"><tt>field_flags_lo</tt></td> 7698 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7699 <td headers="list_of_all_bands_l"> 7700 <tt>[SUM(*class_field_count)]</tt></td> 7701 <td headers="list_of_all_bands_c"> </td> 7702 </tr> 7703 <tr> 7704 <td headers="list_of_all_bands_b"><tt>field_attr_count</tt></td> 7705 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7706 <td headers="list_of_all_bands_l"> 7707 <tt>[COUNT(1<<16,...)]</tt></td> 7708 <td headers="list_of_all_bands_c"> </td> 7709 </tr> 7710 <tr> 7711 <td headers="list_of_all_bands_b"><tt>field_attr_indexes</tt></td> 7712 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7713 <td headers="list_of_all_bands_l"> 7714 <tt>[SUM(*field_attr_count)]</tt></td> 7715 <td headers="list_of_all_bands_c"> </td> 7716 </tr> 7717 <tr> 7718 <td headers="list_of_all_bands_b"><tt>field_attr_calls</tt></td> 7719 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7720 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7721 <td headers="list_of_all_bands_c"> </td> 7722 </tr> 7723 <tr> 7724 <td headers="list_of_all_bands_b"> 7725 <tt>field_ConstantValue_KQ</tt></td> 7726 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7727 <td headers="list_of_all_bands_l"> 7728 <tt>[COUNT(ConstantValue,...)]</tt></td> 7729 <td headers="list_of_all_bands_c"><tt>cp_Int, cp_Float, 7730 etc.</tt></td> 7731 </tr> 7732 <tr> 7733 <td headers="list_of_all_bands_b"><tt>field_Signature_RS</tt></td> 7734 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7735 <td headers="list_of_all_bands_l"> 7736 <tt>[COUNT(Signature,...)]</tt></td> 7737 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7738 </tr> 7739 <tr> 7740 <td headers="list_of_all_bands_b"><tt>field_RVA_anno_N</tt></td> 7741 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7742 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7743 <td headers="list_of_all_bands_c"> </td> 7744 </tr> 7745 <tr> 7746 <td headers="list_of_all_bands_b"><tt>field_RVA_type_RS</tt></td> 7747 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7748 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7749 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7750 </tr> 7751 <tr> 7752 <td headers="list_of_all_bands_b"><tt>field_RVA_pair_N</tt></td> 7753 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7754 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7755 <td headers="list_of_all_bands_c"> </td> 7756 </tr> 7757 <tr> 7758 <td headers="list_of_all_bands_b"><tt>field_RVA_name_RU</tt></td> 7759 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7760 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7761 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7762 </tr> 7763 <tr> 7764 <td headers="list_of_all_bands_b"><tt>field_RVA_T</tt></td> 7765 <td headers="list_of_all_bands_d">BYTE1</td> 7766 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7767 <td headers="list_of_all_bands_c"> </td> 7768 </tr> 7769 <tr> 7770 <td headers="list_of_all_bands_b"><tt>field_RVA_caseI_KI</tt></td> 7771 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7772 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7773 <td headers="list_of_all_bands_c"><tt>cp_Int</tt></td> 7774 </tr> 7775 <tr> 7776 <td headers="list_of_all_bands_b"><tt>field_RVA_caseD_KD</tt></td> 7777 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7778 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7779 <td headers="list_of_all_bands_c"><tt>cp_Double</tt></td> 7780 </tr> 7781 <tr> 7782 <td headers="list_of_all_bands_b"><tt>field_RVA_caseF_KF</tt></td> 7783 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7784 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7785 <td headers="list_of_all_bands_c"><tt>cp_Float</tt></td> 7786 </tr> 7787 <tr> 7788 <td headers="list_of_all_bands_b"><tt>field_RVA_caseJ_KJ</tt></td> 7789 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7790 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7791 <td headers="list_of_all_bands_c"><tt>cp_Long</tt></td> 7792 </tr> 7793 <tr> 7794 <td headers="list_of_all_bands_b"><tt>field_RVA_casec_RS</tt></td> 7795 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7796 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7797 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7798 </tr> 7799 <tr> 7800 <td headers="list_of_all_bands_b"><tt>field_RVA_caseet_RS</tt></td> 7801 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7802 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7803 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7804 </tr> 7805 <tr> 7806 <td headers="list_of_all_bands_b"><tt>field_RVA_caseec_RU</tt></td> 7807 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7808 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7809 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7810 </tr> 7811 <tr> 7812 <td headers="list_of_all_bands_b"><tt>field_RVA_cases_RU</tt></td> 7813 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7814 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7815 <td headers="list_of_all_bands_d"><tt>cp_Utf8</tt></td> 7816 </tr> 7817 <tr> 7818 <td headers="list_of_all_bands_b"> 7819 <tt>field_RVA_casearray_N</tt></td> 7820 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7821 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7822 <td headers="list_of_all_bands_c"> </td> 7823 </tr> 7824 <tr> 7825 <td headers="list_of_all_bands_b"> 7826 <tt>field_RVA_nesttype_RS</tt></td> 7827 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7828 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7829 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7830 </tr> 7831 <tr> 7832 <td headers="list_of_all_bands_b"> 7833 <tt>field_RVA_nestpair_N</tt></td> 7834 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7835 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7836 <td headers="list_of_all_bands_c"> </td> 7837 </tr> 7838 <tr> 7839 <td headers="list_of_all_bands_b"> 7840 <tt>field_RVA_nestname_RU</tt></td> 7841 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7842 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7843 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7844 </tr> 7845 <tr> 7846 <td headers="list_of_all_bands_b"><tt>field_RIA_anno_N</tt></td> 7847 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7848 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7849 <td headers="list_of_all_bands_c"> </td> 7850 </tr> 7851 <tr> 7852 <td headers="list_of_all_bands_b"><tt>{field_RIA_...}</tt></td> 7853 <td headers="list_of_all_bands_d"></td> 7854 <td headers="list_of_all_bands_l"></td> 7855 <td headers="list_of_all_bands_c"> </td> 7856 </tr> 7857 <tr> 7858 <td headers="list_of_all_bands_b"> 7859 <tt>field_RIA_nestname_RU</tt></td> 7860 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7861 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7862 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7863 </tr> 7864 <tr> 7865 <td headers="list_of_all_bands_b"> 7866 <tt>{field_attr_element_bands...}</tt></td> 7867 <td headers="list_of_all_bands_d">(various)</td> 7868 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7869 <td headers="list_of_all_bands_c"><tt>(various)</tt></td> 7870 </tr> 7871 <tr> 7872 <td headers="list_of_all_bands_b"><tt>method_descr</tt></td> 7873 <td headers="list_of_all_bands_d">MDELTA5</td> 7874 <td headers="list_of_all_bands_l"> 7875 <tt>[SUM(*class_method_count)]</tt></td> 7876 <td headers="list_of_all_bands_c"><tt>cp_Descr</tt></td> 7877 </tr> 7878 <tr> 7879 <td headers="list_of_all_bands_b"><tt>method_flags_hi</tt></td> 7880 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7881 <td headers="list_of_all_bands_l"> 7882 <tt>[SUM(*class_method_count)*#have_method_flags_hi]</tt></td> 7883 <td headers="list_of_all_bands_c"> </td> 7884 </tr> 7885 <tr> 7886 <td headers="list_of_all_bands_b"><tt>method_flags_lo</tt></td> 7887 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7888 <td headers="list_of_all_bands_l"> 7889 <tt>[SUM(*class_method_count)]</tt></td> 7890 <td headers="list_of_all_bands_c"> </td> 7891 </tr> 7892 <tr> 7893 <td headers="list_of_all_bands_b"><tt>method_attr_count</tt></td> 7894 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7895 <td headers="list_of_all_bands_l"> 7896 <tt>[COUNT(1<<16,...)]</tt></td> 7897 <td headers="list_of_all_bands_c"> </td> 7898 </tr> 7899 <tr> 7900 <td headers="list_of_all_bands_b"><tt>method_attr_indexes</tt></td> 7901 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7902 <td headers="list_of_all_bands_l"> 7903 <tt>[SUM(*method_attr_count)]</tt></td> 7904 <td headers="list_of_all_bands_c"> </td> 7905 </tr> 7906 <tr> 7907 <td headers="list_of_all_bands_b"><tt>method_attr_calls</tt></td> 7908 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7909 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7910 <td headers="list_of_all_bands_c"> </td> 7911 </tr> 7912 <tr> 7913 <td headers="list_of_all_bands_b"><tt>method_Exceptions_N</tt></td> 7914 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7915 <td headers="list_of_all_bands_l"> 7916 <tt>[COUNT(Exceptions,...)]</tt></td> 7917 <td headers="list_of_all_bands_c"> </td> 7918 </tr> 7919 <tr> 7920 <td headers="list_of_all_bands_b"> 7921 <tt>method_Exceptions_RC</tt></td> 7922 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7923 <td headers="list_of_all_bands_l"> 7924 <tt>[SUM(*method_Exceptions_N)]</tt></td> 7925 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 7926 </tr> 7927 <tr> 7928 <td headers="list_of_all_bands_b"><tt>method_Signature_RS</tt></td> 7929 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7930 <td headers="list_of_all_bands_l"> 7931 <tt>[COUNT(Signature,...)]</tt></td> 7932 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7933 </tr> 7934 <tr> 7935 <td headers="list_of_all_bands_b"><tt>method_RVA_anno_N</tt></td> 7936 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7937 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7938 <td headers="list_of_all_bands_c"> </td> 7939 </tr> 7940 <tr> 7941 <td headers="list_of_all_bands_b"><tt>method_RVA_type_RS</tt></td> 7942 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7943 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7944 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7945 </tr> 7946 <tr> 7947 <td headers="list_of_all_bands_b"><tt>method_RVA_pair_N</tt></td> 7948 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7949 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7950 <td headers="list_of_all_bands_c"> </td> 7951 </tr> 7952 <tr> 7953 <td headers="list_of_all_bands_b"><tt>method_RVA_name_RU</tt></td> 7954 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7955 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7956 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 7957 </tr> 7958 <tr> 7959 <td headers="list_of_all_bands_b"><tt>method_RVA_T</tt></td> 7960 <td headers="list_of_all_bands_d">BYTE1</td> 7961 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7962 <td headers="list_of_all_bands_c"> </td> 7963 </tr> 7964 <tr> 7965 <td headers="list_of_all_bands_b"><tt>method_RVA_caseI_KI</tt></td> 7966 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7967 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7968 <td headers="list_of_all_bands_c"><tt>cp_Int</tt></td> 7969 </tr> 7970 <tr> 7971 <td headers="list_of_all_bands_b"><tt>method_RVA_caseD_KD</tt></td> 7972 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7973 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7974 <td headers="list_of_all_bands_c"><tt>cp_Double</tt></td> 7975 </tr> 7976 <tr> 7977 <td headers="list_of_all_bands_b"><tt>method_RVA_caseF_KF</tt></td> 7978 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7979 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7980 <td headers="list_of_all_bands_c"><tt>cp_Float</tt></td> 7981 </tr> 7982 <tr> 7983 <td headers="list_of_all_bands_b"><tt>method_RVA_caseJ_KJ</tt></td> 7984 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7985 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7986 <td headers="list_of_all_bands_c"><tt>cp_Long</tt></td> 7987 </tr> 7988 <tr> 7989 <td headers="list_of_all_bands_b"><tt>method_RVA_casec_RS</tt></td> 7990 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7991 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7992 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 7993 </tr> 7994 <tr> 7995 <td headers="list_of_all_bands_b"> 7996 <tt>method_RVA_caseet_RS</tt></td> 7997 <td headers="list_of_all_bands_d">UNSIGNED5</td> 7998 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 7999 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8000 </tr> 8001 <tr> 8002 <td headers="list_of_all_bands_b"> 8003 <tt>method_RVA_caseec_RU</tt></td> 8004 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8005 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8006 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8007 </tr> 8008 <tr> 8009 <td headers="list_of_all_bands_b"><tt>method_RVA_cases_RU</tt></td> 8010 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8011 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8012 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8013 </tr> 8014 <tr> 8015 <td headers="list_of_all_bands_b"> 8016 <tt>method_RVA_casearray_N</tt></td> 8017 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8018 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8019 <td headers="list_of_all_bands_c"> </td> 8020 </tr> 8021 <tr> 8022 <td headers="list_of_all_bands_b"> 8023 <tt>method_RVA_nesttype_RS</tt></td> 8024 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8025 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8026 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8027 </tr> 8028 <tr> 8029 <td headers="list_of_all_bands_b"> 8030 <tt>method_RVA_nestpair_N</tt></td> 8031 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8032 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8033 <td headers="list_of_all_bands_c"> </td> 8034 </tr> 8035 <tr> 8036 <td headers="list_of_all_bands_b"> 8037 <tt>method_RVA_nestname_RU</tt></td> 8038 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8039 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8040 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8041 </tr> 8042 <tr> 8043 <td headers="list_of_all_bands_b"><tt>method_RIA_anno_N</tt></td> 8044 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8045 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8046 <td headers="list_of_all_bands_c"> </td> 8047 </tr> 8048 <tr> 8049 <td headers="list_of_all_bands_b"><tt>{method_RIA_...}</tt></td> 8050 <td headers="list_of_all_bands_d"></td> 8051 <td headers="list_of_all_bands_l"></td> 8052 <td headers="list_of_all_bands_c"> </td> 8053 </tr> 8054 <tr> 8055 <td headers="list_of_all_bands_b"> 8056 <tt>method_RIA_nestname_RU</tt></td> 8057 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8058 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8059 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8060 </tr> 8061 <tr> 8062 <td headers="list_of_all_bands_b"> 8063 <tt>method_RVPA_param_NB</tt></td> 8064 <td headers="list_of_all_bands_d">BYTE1</td> 8065 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8066 <td headers="list_of_all_bands_c"> </td> 8067 </tr> 8068 <tr> 8069 <td headers="list_of_all_bands_b"><tt>method_RVPA_anno_N</tt></td> 8070 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8071 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8072 <td headers="list_of_all_bands_c"> </td> 8073 </tr> 8074 <tr> 8075 <td headers="list_of_all_bands_b"><tt>{method_RVPA_...}</tt></td> 8076 <td headers="list_of_all_bands_d"></td> 8077 <td headers="list_of_all_bands_l"></td> 8078 <td headers="list_of_all_bands_c"> </td> 8079 </tr> 8080 <tr> 8081 <td headers="list_of_all_bands_b"> 8082 <tt>method_RVPA_nestname_RU</tt></td> 8083 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8084 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8085 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8086 </tr> 8087 <tr> 8088 <td headers="list_of_all_bands_b"> 8089 <tt>method_RIPA_param_NB</tt></td> 8090 <td headers="list_of_all_bands_d">BYTE1</td> 8091 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8092 <td headers="list_of_all_bands_c"> </td> 8093 </tr> 8094 <tr> 8095 <td headers="list_of_all_bands_b"><tt>method_RIPA_anno_N</tt></td> 8096 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8097 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8098 <td headers="list_of_all_bands_c"> </td> 8099 </tr> 8100 <tr> 8101 <td headers="list_of_all_bands_b"><tt>{method_RIPA_...}</tt></td> 8102 <td headers="list_of_all_bands_d"></td> 8103 <td headers="list_of_all_bands_l"></td> 8104 <td headers="list_of_all_bands_c"> </td> 8105 </tr> 8106 <tr> 8107 <td headers="list_of_all_bands_b"> 8108 <tt>method_RIPA_nestname_RU</tt></td> 8109 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8110 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8111 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8112 </tr> 8113 <tr> 8114 <td headers="list_of_all_bands_b"><tt>method_AD_T</tt></td> 8115 <td headers="list_of_all_bands_d">BYTE1</td> 8116 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8117 <td headers="list_of_all_bands_c"> </td> 8118 </tr> 8119 <tr> 8120 <td headers="list_of_all_bands_b"><tt>method_AD_caseI_KI</tt></td> 8121 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8122 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8123 <td headers="list_of_all_bands_c"><tt>cp_Int</tt></td> 8124 </tr> 8125 <tr> 8126 <td headers="list_of_all_bands_b"><tt>method_AD_caseD_KD</tt></td> 8127 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8128 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8129 <td headers="list_of_all_bands_c"><tt>cp_Double</tt></td> 8130 </tr> 8131 <tr> 8132 <td headers="list_of_all_bands_b"><tt>method_AD_caseF_KF</tt></td> 8133 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8134 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8135 <td headers="list_of_all_bands_c"><tt>cp_Float</tt></td> 8136 </tr> 8137 <tr> 8138 <td headers="list_of_all_bands_b"><tt>method_AD_caseJ_KJ</tt></td> 8139 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8140 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8141 <td headers="list_of_all_bands_c"><tt>cp_Long</tt></td> 8142 </tr> 8143 <tr> 8144 <td headers="list_of_all_bands_b"><tt>method_AD_casec_RS</tt></td> 8145 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8146 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8147 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8148 </tr> 8149 <tr> 8150 <td headers="list_of_all_bands_b"><tt>method_AD_caseet_RS</tt></td> 8151 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8152 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8153 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8154 </tr> 8155 <tr> 8156 <td headers="list_of_all_bands_b"><tt>method_AD_caseec_RU</tt></td> 8157 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8158 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8159 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8160 </tr> 8161 <tr> 8162 <td headers="list_of_all_bands_b"><tt>method_AD_cases_RU</tt></td> 8163 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8164 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8165 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8166 </tr> 8167 <tr> 8168 <td headers="list_of_all_bands_b"> 8169 <tt>method_AD_casearray_N</tt></td> 8170 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8171 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8172 <td headers="list_of_all_bands_c"> </td> 8173 </tr> 8174 <tr> 8175 <td headers="list_of_all_bands_b"> 8176 <tt>method_AD_nesttype_RS</tt></td> 8177 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8178 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8179 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8180 </tr> 8181 <tr> 8182 <td headers="list_of_all_bands_b"> 8183 <tt>method_AD_nestpair_N</tt></td> 8184 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8185 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8186 <td headers="list_of_all_bands_c"> </td> 8187 </tr> 8188 <tr> 8189 <td headers="list_of_all_bands_b"> 8190 <tt>method_AD_nestname_RU</tt></td> 8191 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8192 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8193 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8194 </tr> 8195 <tr> 8196 <td headers="list_of_all_bands_b"> 8197 <tt>method_MethodParameters_NB</tt></td> 8198 <td headers="list_of_all_bands_d">BYTE1</td> 8199 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8200 <td headers="list_of_all_bands_c"> </td> 8201 </tr> 8202 <tr> 8203 <td headers="list_of_all_bands_b"> 8204 <tt>method_MethodParameters_name_RUN</tt></td> 8205 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8206 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8207 <td headers="list_of_all_bands_c"><tt>null|cp_Utf8</tt></td> 8208 </tr> 8209 <tr> 8210 <td headers="list_of_all_bands_b"> 8211 <tt>method_MethodParameters_flag_FH</tt></td> 8212 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8213 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8214 <td headers="list_of_all_bands_c"> </td> 8215 </tr> 8216 <tr> 8217 <td headers="list_of_all_bands_b"> 8218 <tr> 8219 <td headers="list_of_all_bands_b"> 8220 <tt>{method_attr_element_bands...}</tt></td> 8221 <td headers="list_of_all_bands_d">(various)</td> 8222 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8223 <td headers="list_of_all_bands_c"><tt>(various)</tt></td> 8224 </tr> 8225 <tr> 8226 <td headers="list_of_all_bands_b"><tt>class_flags_hi</tt></td> 8227 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8228 <td headers="list_of_all_bands_l"> 8229 <tt>[#class_count*#have_class_flags_hi]</tt></td> 8230 <td headers="list_of_all_bands_c"> </td> 8231 </tr> 8232 <tr> 8233 <td headers="list_of_all_bands_b"><tt>class_flags_lo</tt></td> 8234 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8235 <td headers="list_of_all_bands_l"><tt>[#class_count]</tt></td> 8236 <td headers="list_of_all_bands_c"> </td> 8237 </tr> 8238 <tr> 8239 <td headers="list_of_all_bands_b"><tt>class_attr_count</tt></td> 8240 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8241 <td headers="list_of_all_bands_l"> 8242 <tt>[COUNT(1<<16,...)]</tt></td> 8243 <td headers="list_of_all_bands_c"> </td> 8244 </tr> 8245 <tr> 8246 <td headers="list_of_all_bands_b"><tt>class_attr_indexes</tt></td> 8247 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8248 <td headers="list_of_all_bands_l"> 8249 <tt>[SUM(*class_attr_count)]</tt></td> 8250 <td headers="list_of_all_bands_c"> </td> 8251 </tr> 8252 <tr> 8253 <td headers="list_of_all_bands_b"><tt>class_attr_calls</tt></td> 8254 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8255 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8256 <td headers="list_of_all_bands_c"> </td> 8257 </tr> 8258 <tr> 8259 <td headers="list_of_all_bands_b"> 8260 <tt>class_SourceFile_RUN</tt></td> 8261 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8262 <td headers="list_of_all_bands_l"> 8263 <tt>[COUNT(SourceFile,...)]</tt></td> 8264 <td headers="list_of_all_bands_c"><tt>null|cp_Utf8</tt></td> 8265 </tr> 8266 <tr> 8267 <td headers="list_of_all_bands_b"> 8268 <tt>class_EnclosingMethod_RC</tt></td> 8269 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8270 <td headers="list_of_all_bands_l"> 8271 <tt>[COUNT(EnclosingMethod,...)]</tt></td> 8272 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 8273 </tr> 8274 <tr> 8275 <td headers="list_of_all_bands_b"> 8276 <tt>class_EnclosingMethod_RDN</tt></td> 8277 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8278 <td headers="list_of_all_bands_l"> 8279 <tt>[COUNT(EnclosingMethod,...)]</tt></td> 8280 <td headers="list_of_all_bands_c"><tt>null|cp_Descr</tt></td> 8281 </tr> 8282 <tr> 8283 <td headers="list_of_all_bands_b"><tt>class_Signature_RS</tt></td> 8284 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8285 <td headers="list_of_all_bands_l"> 8286 <tt>[COUNT(Signature,...)]</tt></td> 8287 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8288 </tr> 8289 <tr> 8290 <td headers="list_of_all_bands_b"><tt>class_RVA_anno_N</tt></td> 8291 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8292 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8293 <td headers="list_of_all_bands_c"> </td> 8294 </tr> 8295 <tr> 8296 <td headers="list_of_all_bands_b"><tt>class_RVA_type_RS</tt></td> 8297 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8298 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8299 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8300 </tr> 8301 <tr> 8302 <td headers="list_of_all_bands_b"><tt>class_RVA_pair_N</tt></td> 8303 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8304 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8305 <td headers="list_of_all_bands_c"> </td> 8306 </tr> 8307 <tr> 8308 <td headers="list_of_all_bands_b"><tt>class_RVA_name_RU</tt></td> 8309 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8310 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8311 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8312 </tr> 8313 <tr> 8314 <td headers="list_of_all_bands_b"><tt>class_RVA_T</tt></td> 8315 <td headers="list_of_all_bands_d">BYTE1</td> 8316 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8317 <td headers="list_of_all_bands_c"> </td> 8318 </tr> 8319 <tr> 8320 <td headers="list_of_all_bands_b"><tt>class_RVA_caseI_KI</tt></td> 8321 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8322 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8323 <td headers="list_of_all_bands_c"><tt>cp_Int</tt></td> 8324 </tr> 8325 <tr> 8326 <td headers="list_of_all_bands_b"><tt>class_RVA_caseD_KD</tt></td> 8327 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8328 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8329 <td headers="list_of_all_bands_c"><tt>cp_Double</tt></td> 8330 </tr> 8331 <tr> 8332 <td headers="list_of_all_bands_b"><tt>class_RVA_caseF_KF</tt></td> 8333 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8334 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8335 <td headers="list_of_all_bands_c"><tt>cp_Float</tt></td> 8336 </tr> 8337 <tr> 8338 <td headers="list_of_all_bands_b"><tt>class_RVA_caseJ_KJ</tt></td> 8339 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8340 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8341 <td headers="list_of_all_bands_c"><tt>cp_Long</tt></td> 8342 </tr> 8343 <tr> 8344 <td headers="list_of_all_bands_b"><tt>class_RVA_casec_RS</tt></td> 8345 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8346 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8347 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8348 </tr> 8349 <tr> 8350 <td headers="list_of_all_bands_b"><tt>class_RVA_caseet_RS</tt></td> 8351 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8352 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8353 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8354 </tr> 8355 <tr> 8356 <td headers="list_of_all_bands_b"><tt>class_RVA_caseec_RU</tt></td> 8357 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8358 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8359 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8360 </tr> 8361 <tr> 8362 <td headers="list_of_all_bands_b"><tt>class_RVA_cases_RU</tt></td> 8363 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8364 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8365 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8366 </tr> 8367 <tr> 8368 <td headers="list_of_all_bands_b"> 8369 <tt>class_RVA_casearray_N</tt></td> 8370 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8371 <td headers="list_of_all_bands_c"><tt>[...]</tt></td> 8372 <td headers="list_of_all_bands_l"> </td> 8373 </tr> 8374 <tr> 8375 <td headers="list_of_all_bands_b"> 8376 <tt>class_RVA_nesttype_RS</tt></td> 8377 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8378 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8379 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8380 </tr> 8381 <tr> 8382 <td headers="list_of_all_bands_b"> 8383 <tt>class_RVA_nestpair_N</tt></td> 8384 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8385 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8386 <td headers="list_of_all_bands_c"> </td> 8387 </tr> 8388 <tr> 8389 <td headers="list_of_all_bands_b"> 8390 <tt>class_RVA_nestname_RU</tt></td> 8391 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8392 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8393 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8394 </tr> 8395 <tr> 8396 <td headers="list_of_all_bands_b"><tt>class_RIA_anno_N</tt></td> 8397 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8398 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8399 <td headers="list_of_all_bands_c"> </td> 8400 </tr> 8401 <tr> 8402 <td headers="list_of_all_bands_b"><tt>{class_RIA_...}</tt></td> 8403 <td headers="list_of_all_bands_d"></td> 8404 <td headers="list_of_all_bands_l"></td> 8405 <td headers="list_of_all_bands_c"> </td> 8406 </tr> 8407 <tr> 8408 <td headers="list_of_all_bands_b"> 8409 <tt>class_RIA_nestname_RU</tt></td> 8410 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8411 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8412 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8413 </tr> 8414 <tr> 8415 <td headers="list_of_all_bands_b"> 8416 <tt>class_InnerClasses_N</tt></td> 8417 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8418 <td headers="list_of_all_bands_l"> 8419 <tt>[COUNT(InnerClasses,...)]</tt></td> 8420 <td headers="list_of_all_bands_c"> </td> 8421 </tr> 8422 <tr> 8423 <td headers="list_of_all_bands_b"> 8424 <tt>class_InnerClasses_RC</tt></td> 8425 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8426 <td headers="list_of_all_bands_l"> 8427 <tt>[SUM(*class_InnerClasses_N)]</tt></td> 8428 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 8429 </tr> 8430 <tr> 8431 <td headers="list_of_all_bands_b"> 8432 <tt>class_InnerClasses_F</tt></td> 8433 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8434 <td headers="list_of_all_bands_l"> 8435 <tt>[SUM(*class_InnerClasses_N)]</tt></td> 8436 <td headers="list_of_all_bands_c"> </td> 8437 </tr> 8438 <tr> 8439 <td headers="list_of_all_bands_b"> 8440 <tt>class_InnerClasses_outer_RCN</tt></td> 8441 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8442 <td headers="list_of_all_bands_l"> 8443 <tt>[COUNT(!=0,*class_InnerClasses_F)]</tt></td> 8444 <td headers="list_of_all_bands_c"><tt>null|cp_Class</tt></td> 8445 </tr> 8446 <tr> 8447 <td headers="list_of_all_bands_b"> 8448 <tt>class_InnerClasses_name_RUN</tt></td> 8449 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8450 <td headers="list_of_all_bands_l"> 8451 <tt>[COUNT(!=0,*class_InnerClasses_F)]</tt></td> 8452 <td headers="list_of_all_bands_c"><tt>null|cp_Utf8</tt></td> 8453 </tr> 8454 <tr> 8455 <td headers="list_of_all_bands_b"> 8456 <tt>class_file_version_minor_H</tt></td> 8457 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8458 <td headers="list_of_all_bands_l"> 8459 <tt>[COUNT(version,...)]</tt></td> 8460 <td headers="list_of_all_bands_c"> </td> 8461 </tr> 8462 <tr> 8463 <td headers="list_of_all_bands_b"> 8464 <tt>class_file_version_major_H</tt></td> 8465 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8466 <td headers="list_of_all_bands_l"> 8467 <tt>[COUNT(version,...)]</tt></td> 8468 <td headers="list_of_all_bands_c"> </td> 8469 </tr> 8470 <tr> 8471 <td headers="list_of_all_bands_b"> 8472 <tt>{class_attr_element_bands...}</tt></td> 8473 <td headers="list_of_all_bands_d">(various)</td> 8474 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8475 <td headers="list_of_all_bands_c"><tt>(various)</tt></td> 8476 </tr> 8477 <tr> 8478 <td headers="list_of_all_bands_b"><tt>code_headers</tt></td> 8479 <td headers="list_of_all_bands_d">BYTE1</td> 8480 <td headers="list_of_all_bands_l"><tt>[COUNT(Code,...)]</tt></td> 8481 <td headers="list_of_all_bands_c"> </td> 8482 </tr> 8483 <tr> 8484 <td headers="list_of_all_bands_b"><tt>code_max_stack</tt></td> 8485 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8486 <td headers="list_of_all_bands_l"> 8487 <tt>[COUNT(0,*code_headers)]</tt></td> 8488 <td headers="list_of_all_bands_c"> </td> 8489 </tr> 8490 <tr> 8491 <td headers="list_of_all_bands_b"><tt>code_max_na_locals</tt></td> 8492 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8493 <td headers="list_of_all_bands_l"> 8494 <tt>[COUNT(0,*code_headers)]</tt></td> 8495 <td headers="list_of_all_bands_c"> </td> 8496 </tr> 8497 <tr> 8498 <td headers="list_of_all_bands_b"><tt>code_handler_count</tt></td> 8499 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8500 <td headers="list_of_all_bands_l"> 8501 <tt>[COUNT(0,*code_headers)]</tt></td> 8502 <td headers="list_of_all_bands_c"> </td> 8503 </tr> 8504 <tr> 8505 <td headers="list_of_all_bands_b"> 8506 <tt>code_handler_start_P</tt></td> 8507 <td headers="list_of_all_bands_d">BCI5</td> 8508 <td headers="list_of_all_bands_l"> 8509 <tt>[SUM(*code_header_count)]</tt></td> 8510 <td headers="list_of_all_bands_c"> </td> 8511 </tr> 8512 <tr> 8513 <td headers="list_of_all_bands_b"><tt>code_handler_end_PO</tt></td> 8514 <td headers="list_of_all_bands_d">BRANCH5</td> 8515 <td headers="list_of_all_bands_l"> 8516 <tt>[SUM(*code_header_count)]</tt></td> 8517 <td headers="list_of_all_bands_c"> </td> 8518 </tr> 8519 <tr> 8520 <td headers="list_of_all_bands_b"> 8521 <tt>code_handler_catch_PO</tt></td> 8522 <td headers="list_of_all_bands_d">BRANCH5</td> 8523 <td headers="list_of_all_bands_l"> 8524 <tt>[SUM(*code_header_count)]</tt></td> 8525 <td headers="list_of_all_bands_c"> </td> 8526 </tr> 8527 <tr> 8528 <td headers="list_of_all_bands_b"> 8529 <tt>code_handler_class_RCN</tt></td> 8530 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8531 <td headers="list_of_all_bands_l"> 8532 <tt>[SUM(*code_header_count)]</tt></td> 8533 <td headers="list_of_all_bands_c"><tt>null|cp_Class</tt></td> 8534 </tr> 8535 <tr> 8536 <td headers="list_of_all_bands_b"><tt>code_flags_hi</tt></td> 8537 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8538 <td headers="list_of_all_bands_l"> 8539 <tt>[...*#have_code_flags_hi]</tt></td> 8540 <td headers="list_of_all_bands_c"> </td> 8541 </tr> 8542 <tr> 8543 <td headers="list_of_all_bands_b"><tt>code_flags_lo</tt></td> 8544 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8545 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8546 <td headers="list_of_all_bands_c"> </td> 8547 </tr> 8548 <tr> 8549 <td headers="list_of_all_bands_b"><tt>code_attr_count</tt></td> 8550 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8551 <td headers="list_of_all_bands_l"> 8552 <tt>[COUNT(1<<16,...)]</tt></td> 8553 <td headers="list_of_all_bands_c"> </td> 8554 </tr> 8555 <tr> 8556 <td headers="list_of_all_bands_b"><tt>code_attr_indexes</tt></td> 8557 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8558 <td headers="list_of_all_bands_l"> 8559 <tt>[SUM(*code_attr_count)]</tt></td> 8560 <td headers="list_of_all_bands_c"> </td> 8561 </tr> 8562 <tr> 8563 <td headers="list_of_all_bands_b"><tt>code_attr_calls</tt></td> 8564 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8565 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8566 <td headers="list_of_all_bands_c"> </td> 8567 </tr> 8568 <tr> 8569 <td headers="list_of_all_bands_b"> 8570 <tt>code_StackMapTable_N</tt></td> 8571 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8572 <td headers="list_of_all_bands_l"> 8573 <tt>[COUNT(StackMapTable,...)]</tt></td> 8574 <td headers="list_of_all_bands_c"> </td> 8575 </tr> 8576 <tr> 8577 <td headers="list_of_all_bands_b"> 8578 <tt>code_StackMapTable_frame_T</tt></td> 8579 <td headers="list_of_all_bands_d">BYTE1</td> 8580 <td headers="list_of_all_bands_l"> 8581 <tt>[SUM(*code_StackMapTable_N)]</tt></td> 8582 <td headers="list_of_all_bands_c"> </td> 8583 </tr> 8584 <tr> 8585 <td headers="list_of_all_bands_b"> 8586 <tt>code_StackMapTable_local_N</tt></td> 8587 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8588 <td headers="list_of_all_bands_l"> 8589 <tt>[COUNT(255,*code_StackMapTable_frame_T)]</tt></td> 8590 <td headers="list_of_all_bands_c"> </td> 8591 </tr> 8592 <tr> 8593 <td headers="list_of_all_bands_b"> 8594 <tt>code_StackMapTable_stack_N</tt></td> 8595 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8596 <td headers="list_of_all_bands_l"> 8597 <tt>[COUNT(255,*code_StackMapTable_frame_T)]</tt></td> 8598 <td headers="list_of_all_bands_c"> </td> 8599 </tr> 8600 <tr> 8601 <td headers="list_of_all_bands_b"> 8602 <tt>code_StackMapTable_offset</tt></td> 8603 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8604 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8605 <td headers="list_of_all_bands_c"> </td> 8606 </tr> 8607 <tr> 8608 <td headers="list_of_all_bands_b"> 8609 <tt>code_StackMapTable_T</tt></td> 8610 <td headers="list_of_all_bands_d">BYTE1</td> 8611 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8612 <td headers="list_of_all_bands_c"> </td> 8613 </tr> 8614 <tr> 8615 <td headers="list_of_all_bands_b"> 8616 <tt>code_StackMapTable_RC</tt></td> 8617 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8618 <td headers="list_of_all_bands_l"> 8619 <tt>[COUNT(7,*code_StackMapTable_T)]</tt></td> 8620 <td headers="list_of_all_bands_c"> </td> 8621 </tr> 8622 <tr> 8623 <td headers="list_of_all_bands_b"> 8624 <tt>code_StackMapTable_P</tt></td> 8625 <td headers="list_of_all_bands_d">BCI5</td> 8626 <td headers="list_of_all_bands_l"> 8627 <tt>[COUNT(8,*code_StackMapTable_T)]</tt></td> 8628 <td headers="list_of_all_bands_c"> </td> 8629 </tr> 8630 <tr> 8631 <td headers="list_of_all_bands_b"> 8632 <tt>code_LineNumberTable_N</tt></td> 8633 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8634 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8635 <td headers="list_of_all_bands_c"> </td> 8636 </tr> 8637 <tr> 8638 <td headers="list_of_all_bands_b"> 8639 <tt>code_LineNumberTable_bci_P</tt></td> 8640 <td headers="list_of_all_bands_d">BCI5</td> 8641 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8642 <td headers="list_of_all_bands_c"> </td> 8643 </tr> 8644 <tr> 8645 <td headers="list_of_all_bands_b"> 8646 <tt>code_LineNumberTable_line</tt></td> 8647 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8648 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8649 <td headers="list_of_all_bands_c"> </td> 8650 </tr> 8651 <tr> 8652 <td headers="list_of_all_bands_b"> 8653 <tt>code_LocalVariableTable_N</tt></td> 8654 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8655 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8656 <td headers="list_of_all_bands_c"> </td> 8657 </tr> 8658 <tr> 8659 <td headers="list_of_all_bands_b"> 8660 <tt>code_LocalVariableTable_bci_P</tt></td> 8661 <td headers="list_of_all_bands_d">BCI5</td> 8662 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8663 <td headers="list_of_all_bands_c"> </td> 8664 </tr> 8665 <tr> 8666 <td headers="list_of_all_bands_b"> 8667 <tt>code_LocalVariableTable_span_O</tt></td> 8668 <td headers="list_of_all_bands_d">BRANCH5</td> 8669 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8670 <td headers="list_of_all_bands_c"> </td> 8671 </tr> 8672 <tr> 8673 <td headers="list_of_all_bands_b"> 8674 <tt>code_LocalVariableTable_name_RU</tt></td> 8675 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8676 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8677 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8678 </tr> 8679 <tr> 8680 <td headers="list_of_all_bands_b"> 8681 <tt>code_LocalVariableTable_type_RS</tt></td> 8682 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8683 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8684 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8685 </tr> 8686 <tr> 8687 <td headers="list_of_all_bands_b"> 8688 <tt>code_LocalVariableTable_slot</tt></td> 8689 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8690 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8691 <td headers="list_of_all_bands_c"> </td> 8692 </tr> 8693 <tr> 8694 <td headers="list_of_all_bands_b"> 8695 <tt>code_LocalVariableTypeTable_N</tt></td> 8696 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8697 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8698 <td headers="list_of_all_bands_c"> </td> 8699 </tr> 8700 <tr> 8701 <td headers="list_of_all_bands_b"> 8702 <tt>code_LocalVariableTypeTable_bci_P</tt></td> 8703 <td headers="list_of_all_bands_d">BCI5</td> 8704 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8705 <td headers="list_of_all_bands_c"> </td> 8706 </tr> 8707 <tr> 8708 <td headers="list_of_all_bands_b"> 8709 <tt>code_LocalVariableTypeTable_span_O</tt></td> 8710 <td headers="list_of_all_bands_d">BRANCH5</td> 8711 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8712 <td headers="list_of_all_bands_c"> </td> 8713 </tr> 8714 <tr> 8715 <td headers="list_of_all_bands_b"> 8716 <tt>code_LocalVariableTypeTable_name_RU</tt></td> 8717 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8718 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8719 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8720 </tr> 8721 <tr> 8722 <td headers="list_of_all_bands_b"> 8723 <tt>code_LocalVariableTypeTable_type_RS</tt></td> 8724 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8725 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8726 <td headers="list_of_all_bands_c"><tt>cp_Signature</tt></td> 8727 </tr> 8728 <tr> 8729 <td headers="list_of_all_bands_b"> 8730 <tt>code_LocalVariableTypeTable_slot</tt></td> 8731 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8732 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8733 <td headers="list_of_all_bands_c"> </td> 8734 </tr> 8735 <tr> 8736 <td headers="list_of_all_bands_b"> 8737 <tt>{code_attr_element_bands...}</tt></td> 8738 <td headers="list_of_all_bands_d">(various)</td> 8739 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8740 <td headers="list_of_all_bands_c"><tt>(various)</tt></td> 8741 </tr> 8742 <tr> 8743 <td headers="list_of_all_bands_b"><tt>bc_codes</tt></td> 8744 <td headers="list_of_all_bands_d">BYTE1</td> 8745 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8746 <td headers="list_of_all_bands_c"> </td> 8747 </tr> 8748 <tr> 8749 <td headers="list_of_all_bands_b"><tt>bc_case_count</tt></td> 8750 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8751 <td headers="list_of_all_bands_l"> 8752 <tt>[COUNT(switch,*bc_codes)]</tt></td> 8753 <td headers="list_of_all_bands_c"> </td> 8754 </tr> 8755 <tr> 8756 <td headers="list_of_all_bands_b"><tt>bc_case_value</tt></td> 8757 <td headers="list_of_all_bands_d">DELTA5</td> 8758 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8759 <td headers="list_of_all_bands_c"> </td> 8760 </tr> 8761 <tr> 8762 <td headers="list_of_all_bands_b"><tt>bc_byte</tt></td> 8763 <td headers="list_of_all_bands_d">BYTE1</td> 8764 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8765 <td headers="list_of_all_bands_c"> </td> 8766 </tr> 8767 <tr> 8768 <td headers="list_of_all_bands_b"><tt>bc_short</tt></td> 8769 <td headers="list_of_all_bands_d">DELTA5</td> 8770 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8771 <td headers="list_of_all_bands_c"> </td> 8772 </tr> 8773 <tr> 8774 <td headers="list_of_all_bands_b"><tt>bc_local</tt></td> 8775 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8776 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8777 <td headers="list_of_all_bands_c"> </td> 8778 </tr> 8779 <tr> 8780 <td headers="list_of_all_bands_b"><tt>bc_label</tt></td> 8781 <td headers="list_of_all_bands_d">BRANCH5</td> 8782 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8783 <td headers="list_of_all_bands_c"> </td> 8784 </tr> 8785 <tr> 8786 <td headers="list_of_all_bands_b"><tt>bc_intref</tt></td> 8787 <td headers="list_of_all_bands_d">DELTA5</td> 8788 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8789 <td headers="list_of_all_bands_c"><tt>cp_Int</tt></td> 8790 </tr> 8791 <tr> 8792 <td headers="list_of_all_bands_b"><tt>bc_floatref</tt></td> 8793 <td headers="list_of_all_bands_d">DELTA5</td> 8794 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8795 <td headers="list_of_all_bands_c"><tt>cp_Float</tt></td> 8796 </tr> 8797 <tr> 8798 <td headers="list_of_all_bands_b"><tt>bc_longref</tt></td> 8799 <td headers="list_of_all_bands_d">DELTA5</td> 8800 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8801 <td headers="list_of_all_bands_c"><tt>cp_Long</tt></td> 8802 </tr> 8803 <tr> 8804 <td headers="list_of_all_bands_b"><tt>bc_doubleref</tt></td> 8805 <td headers="list_of_all_bands_d">DELTA5</td> 8806 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8807 <td headers="list_of_all_bands_c"><tt>cp_Double</tt></td> 8808 </tr> 8809 <tr> 8810 <td headers="list_of_all_bands_b"><tt>bc_stringref</tt></td> 8811 <td headers="list_of_all_bands_d">DELTA5</td> 8812 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8813 <td headers="list_of_all_bands_c"><tt>cp_String</tt></td> 8814 </tr> 8815 <tr> 8816 <td headers="list_of_all_bands_b"><tt>bc_loadablevalueref</tt></td> 8817 <td headers="list_of_all_bands_d">DELTA5</td> 8818 <td headers="list_of_all_bands_l"> 8819 <tt>[COUNT({qldc,qldc_w},*bc_codes)]</tt></td> 8820 <td headers="list_of_all_bands_c"><tt>cp_All</tt></td> 8821 </tr> 8822 <tr> 8823 <td headers="list_of_all_bands_b"><tt>bc_classref</tt></td> 8824 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8825 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8826 <td headers="list_of_all_bands_c"><tt>cp_Class</tt></td> 8827 </tr> 8828 <tr> 8829 <td headers="list_of_all_bands_b"><tt>bc_fieldref</tt></td> 8830 <td headers="list_of_all_bands_d">DELTA5</td> 8831 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8832 <td headers="list_of_all_bands_c"><tt>cp_Field</tt></td> 8833 </tr> 8834 <tr> 8835 <td headers="list_of_all_bands_b"><tt>bc_methodref</tt></td> 8836 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8837 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8838 <td headers="list_of_all_bands_c"><tt>cp_Method</tt></td> 8839 </tr> 8840 <tr> 8841 <td headers="list_of_all_bands_b"><tt>bc_imethodref</tt></td> 8842 <td headers="list_of_all_bands_d">DELTA5</td> 8843 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8844 <td headers="list_of_all_bands_c"><tt>cp_Imethod</tt></td> 8845 </tr> 8846 <tr> 8847 <td headers="list_of_all_bands_b"><tt>bc_thisfield</tt></td> 8848 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8849 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8850 <td headers="list_of_all_bands_c"><tt>cp_Field 8851 subsequence</tt></td> 8852 </tr> 8853 <tr> 8854 <td headers="list_of_all_bands_b"><tt>bc_superfield</tt></td> 8855 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8856 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8857 <td headers="list_of_all_bands_c"><tt>cp_Field 8858 subsequence</tt></td> 8859 </tr> 8860 <tr> 8861 <td headers="list_of_all_bands_b"><tt>bc_thismethod</tt></td> 8862 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8863 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8864 <td headers="list_of_all_bands_c"><tt>cp_Method 8865 subsequence</tt></td> 8866 </tr> 8867 <tr> 8868 <td headers="list_of_all_bands_b"><tt>bc_supermethod</tt></td> 8869 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8870 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8871 <td headers="list_of_all_bands_c"><tt>cp_Method 8872 subsequence</tt></td> 8873 </tr> 8874 <tr> 8875 <td headers="list_of_all_bands_b"><tt>bc_initref</tt></td> 8876 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8877 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8878 <td headers="list_of_all_bands_c"><tt>cp_Method 8879 subsequence</tt></td> 8880 </tr> 8881 <tr> 8882 <td headers="list_of_all_bands_b"><tt>bc_escref</tt></td> 8883 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8884 <td headers="list_of_all_bands_l"> 8885 <tt>[COUNT(ref_escape,*bc_codes)]</tt></td> 8886 <td headers="list_of_all_bands_c"><tt>cp_All</tt></td> 8887 </tr> 8888 <tr> 8889 <td headers="list_of_all_bands_b"><tt>bc_escrefsize</tt></td> 8890 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8891 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8892 <td headers="list_of_all_bands_c"> </td> 8893 </tr> 8894 <tr> 8895 <td headers="list_of_all_bands_b"><tt>bc_escsize</tt></td> 8896 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8897 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8898 <td headers="list_of_all_bands_c"> </td> 8899 </tr> 8900 <tr> 8901 <td headers="list_of_all_bands_b"><tt>bc_escbyte</tt></td> 8902 <td headers="list_of_all_bands_d">BYTE1</td> 8903 <td headers="list_of_all_bands_l"><tt>[...]</tt></td> 8904 <td headers="list_of_all_bands_c"> </td> 8905 </tr> 8906 <tr> 8907 <td headers="list_of_all_bands_b"><tt>file_name</tt></td> 8908 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8909 <td headers="list_of_all_bands_l"><tt>[#file_count]</tt></td> 8910 <td headers="list_of_all_bands_c"><tt>cp_Utf8</tt></td> 8911 </tr> 8912 <tr> 8913 <td headers="list_of_all_bands_b"><tt>file_size_hi</tt></td> 8914 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8915 <td headers="list_of_all_bands_l"> 8916 <tt>[#file_count*(#have_file_size_hi)]</tt></td> 8917 <td headers="list_of_all_bands_c"> </td> 8918 </tr> 8919 <tr> 8920 <td headers="list_of_all_bands_b"><tt>file_size_lo</tt></td> 8921 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8922 <td headers="list_of_all_bands_l"><tt>[#file_count]</tt></td> 8923 <td headers="list_of_all_bands_c"> </td> 8924 </tr> 8925 <tr> 8926 <td headers="list_of_all_bands_b"><tt>file_modtime</tt></td> 8927 <td headers="list_of_all_bands_d">DELTA5</td> 8928 <td headers="list_of_all_bands_l"> 8929 <tt>[#file_count*(#have_file_modtime)]</tt></td> 8930 <td headers="list_of_all_bands_c"> </td> 8931 </tr> 8932 <tr> 8933 <td headers="list_of_all_bands_b"><tt>file_options</tt></td> 8934 <td headers="list_of_all_bands_d">UNSIGNED5</td> 8935 <td headers="list_of_all_bands_l"> 8936 <tt>[#file_count*(#have_file_options)]</tt></td> 8937 <td headers="list_of_all_bands_c"> </td> 8938 </tr> 8939 <tr> 8940 <td headers="list_of_all_bands_b"><tt>file_bits</tt></td> 8941 <td headers="list_of_all_bands_d">BYTE1</td> 8942 <td headers="list_of_all_bands_l"><tt>[SUM(*file_size)]</tt></td> 8943 <td headers="list_of_all_bands_c"> </td> 8944 </tr> 8945 </table> 8946 <a name="pseudocode" id="pseudocode"></a> <a name="tocApPsCoIl" id= 8947 "tocApPsCoIl"></a> 8948 <h3>8.2. Appendix: Pseudo-Code Illustrations</h3> 8949 <a name="str_psc" id="str_psc"></a> <a name="tocReUtCoPo" id= 8950 "tocReUtCoPo"></a> 8951 <h4>8.2.1. Representation of <tt>cp_Utf8</tt> Constant Pool</h4> 8952 The following pseudo-code asserts the relations, as described in the section <a href= 8953 "#str_psc_ref">Utf8 Constants</a>, between the band lengths and 8954 contents, and <tt>cp_Utf8</tt> constant pool elements. (This code 8955 merely comments on the specification given above; it does not 8956 itself add new information to the specification.) 8957 <pre class="codeblock"> 8958 assert(cp_Utf8[0].equals("")); 8959 int cursor = 0; 8960 int big_cursor = 0; 8961 for (int i = 1; i < cp_Utf8_count; i++) { 8962 String thisString = cp_Utf8[i]; 8963 8964 int prefix = (i == 1)? 0: cp_Utf8_prefix[i-2]; 8965 int suffix = thisString.length() - prefix; 8966 String prevString = cp_Utf8[i-1]; 8967 String prevPrefix = prevString.substring(0, prefix); 8968 String thisPrefix = thisString.substring(0, prefix); 8969 assert(prevPrefix.equals(thisPrefix)); 8970 8971 int small_suffix = cp_Utf8_suffix[i-1]; 8972 char[] suffix_chars; 8973 int offset; 8974 if (small_suffix != 0) { 8975 assert(suffix == small_suffix); 8976 suffix_chars = cp_Utf8_chars; 8977 offset = cursor; 8978 cursor += suffix; 8979 } else { 8980 assert(suffix == cp_Utf8_big_suffix[big_cursor]); 8981 suffix_chars = cp_Utf8_big_chars[big_cursor]; 8982 offset = 0; 8983 assert(suffix == suffix_chars.length); 8984 big_cursor += 1; 8985 } 8986 String thisSuffix = thisString.substring(prefix); 8987 String theseChars = new String(suffix_chars, offset, suffix); 8988 assert(thisSuffix.equals(theseChars)); 8989 } 8990 assert(cp_Utf8_prefix.length == Math.max(0, cp_Utf8_count-2)); 8991 assert(cp_Utf8_suffix.length == Math.max(0, cp_Utf8_count-1)); 8992 assert(cp_Utf8_chars.length == cursor); 8993 assert(cp_Utf8_big_suffix.length == big_cursor); 8994 assert(cp_Utf8_big_chars.length == big_cursor); 8995 8996 </pre> 8997 <a name="sig_psc" id="sig_psc"></a> <a name="tocReSiCoPo" id= 8998 "tocReSiCoPo"></a> 8999 <h4>8.2.2. Representation of <tt>cp_Signature</tt> Constant 9000 Pool</h4> 9001 The following pseudo-code asserts the relations, as described in the section <a href= 9002 "#sig_psc_ref">Type Signatures</a>, between the band lengths and 9003 contents, and <tt>cp_Signature</tt> constant pool elements. (This 9004 code merely comments on the specification given above; it does not 9005 itself add new information to the specification.) 9006 <pre class="codeblock"> 9007 int cursor = 0; 9008 for (int i = 0; i < cp_Signature_count; i++) { 9009 String sign = cp_Signature[i]; 9010 String form = cp_Signature_form[i]; 9011 int form_ptr = 0; 9012 int sign_ptr = 0; 9013 for (; form_ptr < form.length(); form_ptr++) { 9014 assert(form.charAt(form_ptr) == sign.charAt(sign_ptr)); 9015 sign_ptr += 1; 9016 if (form.charAt(form_ptr) == 'L') { 9017 String cls = cp_Class[cursor]; 9018 assert(sign.startsWith(cls, sign_ptr)); 9019 cursor += 1; 9020 sign_ptr += cls.length(); 9021 } 9022 } 9023 assert(sign_ptr == sign.length()); 9024 } 9025 assert(cp_Signature_form.length == cp_Signature_count); 9026 assert(cp_Signature_classes.length == cursor); 9027 </pre> 9028 <a name="bci_psc" id="bci_psc"></a> <a name="tocReByOf" id= 9029 "tocReByOf"></a> 9030 <h4>8.2.3. Representation of Byte Offsets</h4> 9031 The following pseudo-code asserts the relations, as described in the section <a href= 9032 "#bci_psc_ref">Attribute Layout Definitions</a>, between a byte offset and its 9033 encoding in a band governed by a <tt>bc_index</tt> layout element. 9034 (This code merely comments on the specification given above; it 9035 does not itself add new information to the specification.) 9036 <pre class="codeblock"> 9037 // ins_pos is a display of all instruction boundaries 9038 int[] ins_pos; 9039 ... 9040 Arrays.sort(ins_pos); 9041 assert(ins_pos[0] == 0); 9042 assert(ins_pos[ins_pos.length-1] == bytecodes.length); 9043 int regulars = ins_pos.length; // # instruction boundaries 9044 ... 9045 int renumber_bci(int bci) { 9046 int i = Arrays.binarySearch(ins_pos, bci); 9047 return (i >= 0) ? i : (i == -1) ? bci : ins_pos.length + bci - (-i-1); 9048 } 9049 ... 9050 for (int bci = -100; bci <= bytecodes.length+100; bci++) { 9051 int bci_numbering_for_band = renumber_bci(bci); 9052 int i = Arrays.binarySearch(ins_pos, bci); 9053 if (i >= 0) { 9054 assert(ins_pos[i] == bci); 9055 assert(bci_numbering_for_band < regulars); 9056 assert(bci_numbering_for_band == i); 9057 } else if (0 < bci && bci < bytecodes.length) { 9058 int nexti = (-i-1); // index of next instruction 9059 assert(ins_pos[nexti-1] < bci && bci < ins_pos[nexti]); 9060 int prevRegulars = nexti; 9061 int prevAll = bci; 9062 int prevIrregulars = prevAll - prevRegulars; 9063 assert(bci_numbering_for_band >= regulars); 9064 assert(bci_numbering_for_band == regulars + prevIrregulars); 9065 } else { 9066 // other (random) numbers are unchanged by renumbering 9067 assert(bci_numbering_for_band >= bytecodes.length || 9068 bci_numbering_for_band < 0); 9069 assert(bci_numbering_for_band == bci); 9070 } 9071 } 9072 </pre> 9073 <a name="icn_psc" id="icn_psc"></a> <a name="tocRePrNeClNa" id= 9074 "tocRePrNeClNa"></a> 9075 <h4>8.2.4. Representation of Predictable Nested Class Names</h4> 9076 The following pseudo-code asserts the relations, as described in the section <a href= 9077 "#icn_psc_ref">Nested Classes</a>, between the nested class's 9078 mangled name and the predictable outer and simple names. Note that 9079 searches for the literal characters '/' and '$' must be replaced in 9080 real implementations by searches for the character ranges 9081 associated with the SLASH and DOLLAR nonterminals. (This code 9082 merely comments on the specification given above; it does not 9083 itself add new information to the specification.) 9084 <pre class="codeblock"> 9085 String bcn, predictableOuter, predictableICName; 9086 ... 9087 String name = bcn.substring(bcn.lastIndexOf('/')+1); 9088 int dollar2 = name.lastIndexOf('$'); 9089 assert(predictableICName == null || 9090 (predictableICName.charAt(0) > '9' && 9091 predictableICName.indexOf('$') < 0)); 9092 if (predictableICName == null) { 9093 // bcnCase1 or bcnCase4 9094 assert(predictableOuter == null); 9095 assert(dollar2 == -1 || 9096 dollar2+1 == name.length() || 9097 isDigit(name.charAt(dollar2+1))); 9098 } else if (predictableOuter == null) { 9099 // bcnCase2 9100 assert(name.endsWith("$"+predictableICName)); 9101 int dollar1 = name.substring(0, dollar2).lastIndexOf('$'); 9102 assert(dollar1 >= 0 && dollar1+1 < dollar2); 9103 assert(isDigitString(name.substring(dollar1+1, dollar2))); 9104 } else { 9105 // bcnCase3 9106 assert(bcn.equals(predictableOuter+"$"+predictableICName)); 9107 } 9108 9109 </pre> 9110 <a name="faq" id="faq"></a> <a name="tocAppDes" id="tocAppDes"></a> 9111 <h3>8.3. Appendix: Design FAQ</h3> 9112 This collection of frequently asked questions concerning the 9113 Pack200 archive format is meant to serve as a design rationale. 9114 <a name="tocGenQue" id="tocGenQue"></a> 9115 <h4>8.3.1. General Questions</h4> 9116 <ol> 9117 <li> 9118 <p><b>Why not use an existing generic compression mechanism, such 9119 as <tt>.jar</tt>, <tt>.zip</tt>, or <tt>.tar.gz</tt> files?</b> 9120 First, it is better to know the structure of a thing compressed. 9121 Second, a zip or jar archive is compressed element-wise not 9122 globally. This means that any symbol shared by several classes must 9123 be mentioned independently once in each class file. Third, the 9124 structure of an individual class file is really an interleaving of 9125 many different kind of data, each with their own statistics, which 9126 limits the effectiveness of a single-stream compressor such as 9127 gzip. The specific benefit of reordering the data into bands is 9128 about a factor of two, independently of the quality of the 9129 off-the-shelf compressor used as a post-pass. There are also 9130 significant marginal benefits from the various type-specific 9131 recoding techniques. The net result is to improve a compression 9132 factor from 2-4X to 7-9X.</p> 9133 </li> 9134 <li> 9135 <p><b>Why is this specification so complex?</b> The techniques 9136 described here are the result of much experimentation over several 9137 years. Each feature of this specification is thought to contribute 9138 measurably to the overall compression ratio achieved by this 9139 technology. The authors would be happy to be shown, by benchmarks, 9140 that some given feature can be omitted without significant loss of 9141 compression performance.</p> 9142 <p>(A compression performance multiplier of 1.002 or more for some 9143 particular technique is significant, because such multipliers 9144 accumulate readily into performance that end-users notice. A 9145 multiplier of less than 1.0005 is insignificant.)</p> 9146 </li> 9147 <li> 9148 <p><b>The Pack200 transmission format is closely tied to the 9149 current class file format. Won't it go out of date as soon as the 9150 class file format evolves further?</b> Further developments are 9151 likely to take the form of new attributes or perhaps new bytecodes. 9152 The layout language defined by Pack200 supports a very wide range 9153 of attribute formats, including arbitrary mixes of bytes and 9154 constant pool references. Likewise, the bytecode representation 9155 includes escape operators which can represent arbitrary mixes of 9156 data and constant pool references. Although such constructs will 9157 not compress as optimally as the features for which this 9158 specification is directly designed, it appears that reasonable 9159 future extensions will continue to be transmittable, without 9160 disturbing the compression of current features, and without 9161 requiring decompressors to be updated.</p> 9162 </li> 9163 <li> 9164 <p><b>Since Pack200 is a lossy compression algorithm, won't it 9165 break signed JAR files?</b> Signed JAR files contain secure hashes 9166 over the bytewise contents of individual class files. Any change to 9167 the bits of a class file will change its hash code, making the 9168 innocuous changes of Pack200 indistinguishable from attacks on the 9169 application code.</p> 9170 <p>Pack200, like many other compression algorithms, allows the 9171 compressor many degrees of freedom in choosing the contents of the 9172 compressed archive, but no degrees of freedom in choosing the 9173 contents of the decompressed JAR file. Given a compressed archive, 9174 all compliant Pack200 decompressors must produce the same class 9175 file bytes, for each transmitted class file. This stability of 9176 output persists for class files even if a resource file (such as 9177 the manifest) changes its contents. Thus, for any given class file, 9178 compression may be lossy, but the decompression of each class file 9179 must be exact, in a useful way defined by the Pack200 9180 specification.</p> 9181 <p>This means that a compressor with the right stability properties 9182 can be used to produce a signed, packed JAR using these steps:</p> 9183 <ol> 9184 <li>Pack the original signed JAR file.</li> 9185 <li>Unpack it, producing perturbed class files.</li> 9186 <li>Re-sign it, ensuring that only the manifest changes.</li> 9187 <li>Re-pack it, using the updated manifest.</li> 9188 </ol> 9189 <p>(Note: If this specification allows two compliant decompressors 9190 to produce different JAR archive elements for the same compressed 9191 archive input, it is a bug in the specification. The specification 9192 is thought to be free of such bugs, but if you find one please 9193 report it.)</p> 9194 </li> 9195 <li> 9196 <p><b>What is the relationship between file names in Pack200 9197 archives and file names in JAR (or ZIP) archives or disk files?</b> 9198 Pack200 specifies that file names are transmitted as Utf8 strings. 9199 Since these strings are intended to function as names of JAR 9200 elements in functioning Java applications, the strings must also 9201 conform to Java usage, which also represents pathnames as Utf8 9202 strings in JAR files and 16-bit Unicode in memory. Also, in JAR 9203 files, pathname components are separated by the forward slash 9204 character ('/'), and not by any system-specific character. This 9205 allows class loaders to easily convert the internal representation 9206 of the class names (e.g., "java/lang/Object") to pathnames (e.g., 9207 "java/lang/Object.class").</p> 9208 <p>The Pack200 specification does not dictate the interpretation of 9209 file name strings with respect to any other tool or operating 9210 system. However, the natural mapping would be as coherent as 9211 possible with Java's usages.</p> 9212 </li> 9213 <li> 9214 <p><b>What is the relationship between file dates in JAR (or ZIP) 9215 archives or disk files?</b> Pack200 specifies that file dates are 9216 transmitted as 32-bit counts of seconds relative to Java's time 9217 base (i.e., <tt>System.currentTimeMillis</tt> divided by one 9218 thousand). This provides absolute times relative to UTC, at a 9219 one-second granularity. If an operating system provides more 9220 accurate file times, they must be adjusted to a nearby whole second 9221 before transmission in a Pack200 archive.</p> 9222 <p>JAR and ZIP store dates in local format (i.e., 9223 <tt>"YYYY/MM/DD HH:MM:SS"</tt>) with no timezone 9224 specification. This means that conversion to and from Java's 9225 UTC-based times requires a guess at the timezone under which the 9226 compressor was operating. (This problem is not unique to Pack200. 9227 It is a problem with all uses of ZIP and JAR archives.) For many 9228 purposes, the standard guess is that the decompressor and 9229 compressor were operating in the same timezone and during the same 9230 yearly daylight savings time regime. However, in order to provide 9231 more stability in the times transmitted in Pack200 archives, it is 9232 expected that most compressors and decompressors will agree to use 9233 UTC as the timezone when interpreting ZIP-style local times.</p> 9234 </li> 9235 <li> 9236 <p><b>Doesn't the JEFF file 9237 format also oprovide a class-specific compression algorithm?</b> 9238 Yes, the JEFF Working Group has defined a standard file format 9239 (ISO/IEC 20970) which allows class files to be compressed about 50% 9240 and <i>also</i> loaded directly into memory for interpretive 9241 execution. As compression performance, it is comparable with the 9242 DEFLATE algorithm used within JAR archives. Pack200 provides much 9243 greater compression. However, Pack200 archives are not designed for 9244 direct execution by any virtual machine. The greater compression 9245 level of Pack200 is won at a cost of complexity in the unpacker, a 9246 complexity incompatible with any requirement of direct loading or 9247 execution.</p> 9248 </li> 9249 <li> 9250 <p><b>Why doesn't Pack200 use Huffman encoding? (Same question for 9251 LZW, or BWT, or move-to-front, or any other standard compression 9252 technique.)</b> As a matter of simplicity and division of labor, 9253 Pack200 intentionally focuses on finding and removing large-scale 9254 redundancies specific to class files. Pack200 produces a 9255 byte-oriented output, hopefully with clear patterns and a simple 9256 alphabet statistics. It relies on a post-pass compressor to encode 9257 these bytes in some more efficient string-sharing, bit-sliced 9258 representation.</p> 9259 <p>The following considerations support this design:</p> 9260 <ul> 9261 <li>Repeating similar compression tactics in two places in a 9262 pipeline of transformations can actually degrade overall 9263 compression. For example, doing move-to-front in Pack200 band 9264 transmission would make it harder for the DEFLATE algorithm to 9265 detect repeated patterns, because they would have varying spellings 9266 in the tokens DEFLATE would observe. (Delta encoding also has this 9267 risk, which is why it's optional in Pack200. But, off-the-shelf 9268 back ends don't generally do delta encoding.)</li> 9269 <li>Relying on an off-the-shelf backend for final compression 9270 simplifies the Pack200 design.</li> 9271 <li>It also lets Pack200 leverage the latest byte-oriented 9272 compression tools.</li> 9273 <li>Such factoring also simplifies engineering of packer 9274 heuristics.</li> 9275 <li>The job of Pack200 is to find redundancies and patterns at 9276 class and package scales. It seems cleaner to avoid messing with 9277 byte-level scales.</li> 9278 <li>Some specific standard compression techniques may still be 9279 encumbered by patents, even on simple, self-evident techniques. 9280 Avoiding such patents is a significant cost in engineering a 9281 compressor. We would rather avoid this cost by using a standard 9282 tool.</li> 9283 </ul> 9284 </li> 9285 <li> 9286 <p><b>How does this specification cope with archive format 9287 changes?</b> The major and minor version numbers of a Pack200 9288 archive advertise which version of this standard has been generated 9289 by a packer. Because of the flexibility of attribute 9290 layouts, packers can sometimes represent new classfile formats in 9291 old archive formats, but newer archive formats may be required for 9292 reasons of functionality or performance.</p> 9293 <p>Unpacker implementations are strongly encouraged to support each 9294 standard version of the archive format, since there is not always a 9295 strong alignment between packer and unpacker versions at either end 9296 of a deployment channel. Packer implementations are encouraged to 9297 preserve the ability to emit older archive formats, to maintain 9298 maximum compatibility with unpackers.</p> 9299 <p>The reference implementation chooses to maintain backward 9300 compatibility by producing a 1.5 pack format if the input JAR 9301 archive contains no 1.6 (or newer) classfiles. In general, it will 9302 produce the oldest possible archive version compatible with all the 9303 input classfiles. An empty archive will default to the oldest 9304 archive version, which is 1.5.</p> 9305 </li> 9306 <!-- === TEMPLATE FAQ ITEM: === 9307 9308 <li><p><b> 9309 9310 9311 QQQ? 9312 9313 </b> 9314 9315 AAA. 9316 9317 </p><p> 9318 9319 AAA2. 9320 9321 </p></li> 9322 9323 === --></ol> 9324 </body> 9325 </html> --- EOF ---