Re: [p2-dev] Pack200 compression

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

Peter

Is that implementation
agnostic of pack200/JSR 200? If not, it might be a (legal) issue. See the
thread in the jdk-dev mailing list.

Dani



From:
       Peter
Firmstone <peter.firmstone@xxxxxxxxxxx>
To:
       p2-dev@xxxxxxxxxxx
Date:
       26.06.2018
23:26
Subject:
       Re:
[p2-dev] Pack200 compression
Sent
by:        p2-dev-bounces@xxxxxxxxxxx

---

The library is an OSGi versioned
bundle, the code is Java 5 source, as 
is ASM6.2, ASM is only used during compression, the Harmony code was 
originally Java 1.4 source compatible, so I could in theory, write a 
library that will uncompress Java 11 bytecode with Java 1.4.  Although
a 
1.4 JVM can't run Java 11 bytecode, it could uncompress it.   For
now 
I'm happy to stay at Java 5 though, so any jvm from 1.5 up can in theory
and should in the next year, be able to compress and uncompress the 
latest bytecode.   So it's a matter of maybe refactoring p2's code
to 
retry a couple of times, then dynamically updating to the latest 
libarary version if that fails.

Cheers,

Peter.

On 26/06/2018 5:48 PM, Ed Merks wrote:
>
> Mickael,
>
> I think p2 will currently just fail if pack200 is absent.  It
> definitely could be smart enough to ignore pack200 artifacts if it
> knows it can't unpack them, but I don't think that's currently the
> case.  In fact there was some rather questionable logic in the
code 
> that if some pack200 artifact is downloaded, but it can't be unpacked,
> p2 will download it again, assuming that the artifact it downloaded
is 
> corrupt, and it will try that 200 times (I believe that's the magic
> number) before it tries to just download the plain .jar artifact,
if 
> available.  This of course leads to horrible performance.
>
> But I agree that if there were a Java unpack200 library p2 could use,
> that would be better and perhaps perform better than execing a process.
>
> Keep in mind that one of the "smart" aspects of the current
design of 
> using the JRE's pack200 is that you could update your IDE from say
a 
> version that currently requires Java 8 but is running with Java 9
to a 
> version that actually requires Java 9.   If the library for unpack200
> is included in the IDE itself, it would only know about unpacking
Java 
> 8 and wouldn't be able to unpack Java 9 (leading to the above horrible
> performance problem).
>
> Regards,
> Ed
>
>
> On 26.06.2018 09:11, Mickael Istria wrote:
>> Hi Peter, hi Ed,
>>
>> Thanks Peter for anticipating this upcoming issue!
>> I think relying on a Java-based implementation of pack200 is a
good idea.
>>
>> Indeed, when pack200 is not shipped with the JRE by default, p2
>> wouldn't be able to use it anymore if there is no alternative.
I 
>> think p2 has the necessary smartness (maybe some switches) to
just 
>> ignore pack200 artifacts if we don't have a better solution by
then.
>> In the meantime, I think the best strategy for p2 is just to wait
>> until the removal of pack200 happens, and when it happens, switch
to 
>> whichever best pack200 implementation (could be yours) or simply
drop 
>> pack200 if it happens that the overall state of pack200 in the
Java 
>> community reached a point where we can assume it's dead.
>> I do not have the feeling that p2 project and its contributors
can be 
>> strong drivers about the future of pack200 here because everyone
is 
>> busy with many things, and both p2 and the Eclipse world could
>> survive very well without pack200 (updates would "just"
be a bit 
>> slower). I guess pack200 is not critical enough to p2.
>> But that's an interesting topic to discuss with the community
at 
>> large. I'll make it a topic for the Architecture Council to discuss.
>> Maybe there will be more interest than I expect in actively keeping
>> support of pack200.
>>
>> Cheers,
>>
>>
>> _______________________________________________
>> p2-dev mailing list
>> p2-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
>
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/p2-dev