New candidate JEP: 336: Deprecate the Pack200 Tools and API

[Peter]

Mark,

Can Oracle deprecate the implementation but allow the development of the 
specification to continue?

For example, I'm currently working out how to support the Java 9 
constant pool entries, Module_info and Package_info.

Bit 13 in #archive_options would need to be have_cp_module_counts 
cp_module_counts contains counts

If Java can retain the api and specification (and support the 
specification) while deprecating the current implmentation, then the 
community can use the existing provider mechanism to load any 
implementation.

The #archive_options word is interpreted bitwise. Certain bits are given 
symbolic names as follows, where the LSB is numbered as bit
zero:
Bit Name Meaning if set in #archive_options
0 have_special_formats archive_special_counts contains counts
1 have_cp_numbers cp_number_counts contains counts
2 have_all_code_flags code_flags_lo contains an element for every code
3 have_cp_extra_counts cp_extra_counts contains counts
4 have_file_headers archive_file_counts contains counts
5 deflate_hint request compressed JAR file for all elements
6 have_file_modtime file_modtime contains modtimes
7 have_file_options file_options contains option bits
8 have_file_size_hi file_size_hi contains high-order size words
9 have_class_flags_hi class_flags_hi contains extra attribute flags
10 have_field_flags_hi field_flags_hi contains extra attribute flags
11 have_method_flags_hi method_flags_hi contains extra attribute flags
12 have_code_flags_hi code_flags_hi contains extra attribute flags
13 (unused, must be zero)
... (unused, must be zero)
31 (unused, must be zero)


On 16/06/2018 12:25 AM, mark.reinhold at oracle.com wrote:
> 2018/6/12 13:50:37 -0700, Daniel Megert<daniel_megert at ch.ibm.com>:
>> pack200 is used by the Eclipse update manager a.k.a. p2. The JARed
>> plug-ins are compressed with pack200 and put into a p2 repository.
>> Removing pack200 will make the download (and hence install) of plug-ins
>> much slower. Eclipse would therefore like to keep this technology.
> Is Eclipse willing to sign up to maintain this technology?
>
>>                                                                     If
>> that's not an option, then we would like that the removal does not happen
>> before Java 13.
> Request noted.
>
> - Mark