RFR 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking

[Kumar Srinivasan]

Martin,

as for the documentation as to why this is required,  I missed adding 
them last night,
this is spelled out in several places since JDK5.

See item #4
http://docs.oracle.com/javase/7/docs/technotes/guides/pack200/pack-spec.html#tocGenQue

See para #4
http://javaweb.us.oracle.com/java/re/jdk/8/latest/docs/api/java/util/jar/Pack200.Packer.html

See Steps to Pack a File.
http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/pack200.html#pack200_compression

Thanks
Kumar

> Hi Martin,
>
>> I'm not convinced this feature pulls its weight.
>> I'd like to see more motivation/documentation for this change.
>> It seems like this just adds a post-processing phase which packs and
>> unpacks the jar file (why?)
> Pack200 tends to change the internal structure and ordering within
> a class file, which adds a complication, if someone wants to sign these.
> So a jar file needs to pack and unpacked before signing a jar.
>
>>
>> Users who need to do that could just do that in a shell script without
>> confusing the 99.99% of current jar users.
> The motivating reason is performance, for those who want to simply
> jar up a file and perform the normalization in the same VM and in one
> step,  I realize this can be achieved with ant or a custom tool, however
> not all customers are willing to write their own tool or wish to use ant.
>
> The average jar users need not use this option, the option is optional
> and thus  will not affect 99.99% of the users.
>
> Kumar
>>
>>
>> On Mon, Oct 14, 2013 at 11:44 AM, Alexander Zuev
>> <alexander.zuev at oracle.com>wrote:
>>
>>> Hi,
>>>
>>>    please review my fix for
>>> 8020802: Need an ability to create jar files that are invariant to the
>>> pack200 packing/unpacking
>>> The fix adds new option to the jar command which makes created jars
>>> normalized without the need to invoke the
>>> external program.
>>>
>>> Bug description: 
>>> https://bugs.openjdk.java.net/**browse/JDK-8020802<https://bugs.openjdk.java.net/browse/JDK-8020802>
>>> Webrev with proposed fix: http://cr.openjdk.java.net/~**
>>> kizune/8020802/webrev.01<http://cr.openjdk.java.net/~kizune/8020802/webrev.01> 
>>>
>>>
>>> With best regards,
>>> /Alex
>>>
>