diff --git a/pack-spec.html b/pack-spec.html --- a/pack-spec.html +++ b/pack-spec.html @@ -724,10 +724,12 @@ each JAR element in the output.

The archive_magic_word consists of the four bytes 0xCA, 0xFE, 0xD0, 0x0D. -The #archive_minver must be the number 7. -The #archive_majver must be the number 150. +The #archive_minver must be the number 0. +The #archive_majver must be the number 160. Both of the latter two values may be incremented in the future to reflect small revisions in this file format. + Note that in a previous version of this standard, the minor and +major version numbers were 7 and 150.

@@ -2213,10 +2215,8 @@ attributes. (The predefined layouts are 24 Method RuntimeInvisibleParameterAnnotations 25 Method AnnotationDefault - + + 0 Code StackMapTable 1 Code LineNumberTable @@ -2402,10 +2402,9 @@ specification.) union_case: '(' union_case_tag (',' union_case_tag)* ')' '[' (body)? ']' union_case_tag: - ('-')? (digit)+ - + ( numeral | numeral '-' numeral ) call: - '(' ('-')? (digit)+ ')' + '(' numeral ')' reference: reference_type ( 'N' )? uint_type @@ -2419,6 +2418,9 @@ specification.) 'RU' untyped_ref: 'RQ' + + numeral: + '(' ('-')? (digit)+ ')' digit: ( '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ) @@ -2749,6 +2751,15 @@ layout contains an 'S' character, is 'TB

+In a union tag, two numerals separated by a hyphen specify an +inclusive range. The second number must be greater than the +first. This is an abbreviation for the list of all numerals +from the first to the second, inclusive. The layout is treated +exactly as if the abbreviation were replaced by the complete +list. + +

+ Constant pool references in an attribute may be typed strongly, and transmitted as indexes into one of the archive's constant pools. @@ -3116,7 +3127,7 @@ The layout definitions of the predefined Class Signature RSH - Class (metadata) (see below) + Class (metadata) (see below) Class Deprecated (empty) @@ -3124,7 +3135,7 @@ The layout definitions of the predefined Field Signature RSH - Field (metadata) (see below) + Field (metadata) (see below) Field Deprecated (empty) @@ -3134,14 +3145,11 @@ The layout definitions of the predefined Method Signature RSH - Method (metadata) (see below) + Method (metadata) (see below) Method Deprecated (empty) - + + Code StackMapTable (see below) Code LineNumberTable NH[PHH] @@ -3193,7 +3201,53 @@ Special compression tactics on attribute * handler rows are positively differenced mod code size --> -

+ +

Stack Map Layouts
+ +There is a predefined attribute layout for the +StackMapTable attribute of a Code attribute. +With some whitespace and abbreviation added for readability, +it is as follows: + +

+  [NH[(1)]]
+  [TB
+    (64-127)  [(2)]
+    (248-251) [(1)]
+    (252)     [(1)(2)]
+    (253)     [(1)(2)(2)]
+    (254)     [(1)(2)(2)(2)]
+    (255)     [(1)NH[(2)]NH[(2)]]
+    ()        []
+    ]
+  [H]
+  [TB
+    (7) [RCH]
+    (8) [PH]
+    ()  []
+    ]
+
+ +The following observations may be deduced by comparing this +layout specification with the class file format specification +which defines the StackMapTable attribute. + +The second callable describes a stack_map_frame +structure from the class file format specification. + +Within the union in the second callable, the cases stand for the +following stack_map_frame union members, respectively: +same_locals_1_stack_item_frame, chop_frame +(and also same_frame_extended), append_frame +(for three layout union cases), full_frame, and (in the +default layout union case) same_frame. + +The third and fourth callables describe an offset_delta +value and a verification_type_info structure from the +class file format specification. + + +
Metadata Layouts
The predefined attribute layouts for non-parameter metadata annotations are the same in all three contexts. With some @@ -3238,7 +3292,7 @@ count the number of parameters: [TB...] -

+

Unusual Layout Usages
It is possible for the compressor to emit any number of definitions for the same attribute name. These definitions are @@ -3962,16 +4016,14 @@ if the compressor had in fact defined th *code_attr_count :UNSIGNED5 [COUNT(1<<16,...)] *code_attr_indexes :UNSIGNED5 [SUM(*code_attr_count)] *code_attr_calls :UNSIGNED5 [...] - + *code_StackMapTable_N :UNSIGNED5 [COUNT(StackMapTable,...)] + *code_StackMapTable_frame_T :BYTE1 [SUM(*code_StackMapTable_N)] + *code_StackMapTable_local_N :UNSIGNED5 [COUNT(255,*code_StackMapTable_frame_T)] + *code_StackMapTable_stack_N :UNSIGNED5 [COUNT(255,*code_StackMapTable_frame_T)] + *code_StackMapTable_offset :UNSIGNED5 [...] + *code_StackMapTable_T :BYTE1 [...] + *code_StackMapTable_RC :UNSIGNED5 [COUNT(7,*code_StackMapTable_T)] + *code_StackMapTable_P :BCI5 [COUNT(8,*code_StackMapTable_T)] *code_LineNumberTable_N :UNSIGNED5 [...] *code_LineNumberTable_bci_P :BCI5 [...] *code_LineNumberTable_line :UNSIGNED5 [...] @@ -5789,8 +5841,10 @@ specification.) Note that adaptive coding methods ("RunCode" nonterminals) can -be chained via the "BCode" nonterminal, but cannot be nested via -the "ACode" nonterminal. +be chained via the "BCode" nonterminal, but cannot be nested +directly via the "ACode" nonterminal. + (As the grammar shows, they may be nested indirectly via the +"PopCode" nonterminal.)

@@ -6100,10 +6154,10 @@ FCode, UCode, and TCode. FCode, UCode, and TCode. The offset from 141 bitwise encodes the following data:

The last two values are jointly encoded in the value TDefL. @@ -7059,6 +7113,22 @@ which it would be too tedious to include code_attr_indexes UNSIGNED5 [SUM(*code_attr_count)] code_attr_calls UNSIGNED5 [...] + + code_StackMapTable_N UNSIGNED5 [COUNT(StackMapTable,...)] + + code_StackMapTable_frame_T BYTE1 [SUM(*code_StackMapTable_N)] + + code_StackMapTable_local_N UNSIGNED5 [COUNT(255,*code_StackMapTable_frame_T)] + + code_StackMapTable_stack_N UNSIGNED5 [COUNT(255,*code_StackMapTable_frame_T)] + + code_StackMapTable_offset UNSIGNED5 [...] + + code_StackMapTable_T BYTE1 [...] + + code_StackMapTable_RC UNSIGNED5 [COUNT(7,*code_StackMapTable_T)] + + code_StackMapTable_P BCI5 [COUNT(8,*code_StackMapTable_T)] code_LineNumberTable_N UNSIGNED5 [...] @@ -7588,6 +7658,39 @@ We would rather avoid this cost by using +

  • + +How does this specification cope with archive format changes? + + + +The major and minor version numbers of a Pack200 archive +advertise which version of this standard has been generated by a +packer. As of 2005 there are two versions, 160.0 for Java 6 and +150.7 for Java 5. Because of the flexibility of attribute +layouts, packers can sometimes represent new classfile formats +in old archive formats, but newer archive formats may be +required for reasons of functionality or performance. + +

    + +Unpacker implementations are strongly encouraged to support each +standard version of the archive format, since there is not +always a strong alignment between packer and unpacker versions +at either end of a deployment channel. + Packer implementations are encouraged to preserve the ability to +emit older archive formats, to maintain maximum compatibility +with unpackers. + +

    + +The reference implementation chooses to maintain backward +compatibility by producing a 1.5 pack format if the input JAR +archive contains 1.5 (or lower) classfiles. Otherwise it will +produce a 1.6 pack file. The reference implementation unpacker +is compatible with all previous standard versions. + +