[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Pack200 compression
|
Thanks Ed,
The library currently throws a Pack200Exception with the message
"Invalid segment major version : [version]"
I could make it more specific, such as
IncompatiblePack200VersionException. The question is whether we want
to make that a RuntimeException, so it can bubble up to a point where
you want to deal with it to avoid having to change exceptions on
existing methods.
Regards,
Peter.
On 27/06/2018 3:33 PM, Ed Merks wrote:
Peter,
Note that https://bugs.eclipse.org/bugs/show_bug.cgi?id=536282 was
opened related to this issue.
Certainly it's been a problem mentioned in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536282#c5 for the Oomph
installer which uses p2 heavily, that if the installer say is running
with Java 7 but it's creating an installation that has Java 8 pack200
artifacts available, the install will take forever because of 200
download attempts on each such artifact. A library that can give
proper feedback on the pack200 level it actually supports relative to
the artifact its asked to process could in principle be used to avoid
such a problem (i.e., to download such a thing at most once).
Cheers,
Ed
On 26.06.2018 23:26, Peter Firmstone wrote:
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
_______________________________________________
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
