Re: [cross-project-issues-dev] JarProcessor and Java versions

[Andrew Niefer <aniefer@xxxxxxxxxx>]

Thomas,
Could you please raise a bug about this
on Equinox-incubator and tag it with [prov].  I expect we will need
to do something about this.

-Andrew

Thomas Hallgren <thomas@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

11/30/2007 11:41 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	Re: [cross-project-issues-dev] JarProcessor and Java versions

OK, now I know what's going on. When a Java 1.6 pack200
encounters a jar 
file that contains no classfiles, it doesn't bother maintaining backward
compatibility. So when it packs for instance 
org.eclipse.swt_3.3.2.v3347.jar, it creates a magic that can be unpacked
by Java 1.6 only.

This is perhaps not a bug, but it would be cool if the jarProcessor 
could cater for this and actually refrain from packing files that 
contains no classes.

Thanks for your patience :-)

Regards,
Thomas Hallgren


Thomas Hallgren wrote:
> Andrew, John,
> Thanks for your input. I am using Java 1.6 to do the packaging. The
> problem arises when someone using Java 1.5 tries to unpack.
>
> The whole objective with my exercise is to be able to build Java 1.5
> compatible binaries with only Java 1.6 installed so pointing to a
Java 
> 1.5 version of the pack200 is not an option for me.
>
> I looked at the API docs for pack200. It says that "In order
to 
> maintain backward compatibility, if the input JAR-files are solely
> comprised of 1.5 (or lesser) classfiles, a 1.5 compatible pack file
is 
> produced. Otherwise a 1.6 compatible pack200 file is produced."
So I 
> checked the original zip file and its contained jar files, nested
jar 
> files and all files contained in them. I have no class file that has
a 
> major version higher then 49 (Java 6 is >= 50). The same is true
after 
> the file has been normalized. So something else must be happening.
>
> - thomas
>
>
> Andrew Niefer wrote:
>>
>> If this error message is implying that your classes were compiled
>> 1.6, it would be a good idea to use a 1.6 vm to do the packing.
>> As John points out there is an option to choose the pack200 by
>> setting  system property to the directory containing the
pack200 tools.
>>
>> -Andrew
>>
>>
>>
>> *John Arthorne/Ottawa/IBM@IBMCA*
>> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
>>
>> 11/30/2007 09:28 AM
>> Please respond to
>> Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
>>
>>
>>     
>> To
>>     Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
>> cc
>>     
>> Subject
>>     Re: [cross-project-issues-dev] JarProcessor and
Java versions
>>
>>
>>
>>     
>>
>>
>>
>>
>>
>>
>> This page lists all the options supported by the jar processor:
>>
>> http://wiki.eclipse.org/JarProcessor_Options
>>
>> Note at the bottom of the page there is a system property where
you 
>> can specify the exact pack200 command to use.
>> -- 
>>
>>
>> *Thomas Hallgren <thomas@xxxxxxx>*
>> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
>>
>> 11/29/2007 07:32 PM
>> Please respond to
>> Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
>>
>>     
>> To
>>     Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
>> cc
>>     
>> Subject
>>     [cross-project-issues-dev] JarProcessor and Java
versions
>>
>>
>>
>>
>>     
>>
>>
>>
>>
>>
>>
>> Hi,
>> I'm wondering if there are some options that can be passed to
the
>> Eclipse jarProcessor that will restrict the pack200 to a certain
target
>> level. My objective is to restrict builds to a certain target
level
>> (Java 1.5) regardless of what JVM that is used for the build.
The build
>> uses the ant task 'eclipse.jarProcessor'
>>
>> At present, a machine running Java 1.5 will fail with the following
on
>> the top of the stack:
>>
>> Stack Trace:
>> java.io.IOException: Corrupted pack file: magic/ver = CAFED00D/160.1
>> should be CAFED00D/150.7
>>
>> at com.sun.java.util.jar.pack.NativeUnpack.start(Native Method)
>> at com.sun.java.util.jar.pack.NativeUnpack.run(Unknown Source)
>> at com.sun.java.util.jar.pack.NativeUnpack.run(Unknown Source)
>> at com.sun.java.util.jar.pack.UnpackerImpl.unpack(Unknown Source)
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>   
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev