[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Pack200 compression
|
Understood.
The library doesn't perform downloads, only conversions, currently
downloading is the responsibility of client calling code, this will be
relatively easy to address. I think the java pack200 tool by default
first downloads to a file, then uncompresses it. A Pack200 file is
broken up into segments, currently that's often just one large segment,
however if segments size is reduced, we could stream to memory, without
needing to save to files, but if the file is large, it's probably
advisable to save it to a file first.
Regards,
Peter.
On 27/06/2018 11:34 PM, Ed Merks wrote:
Peter,
Don't get me wrong! I think it will be fine to have a library that's
running in the Java process. The point is just that however the
processing step is handled, if the failure isn't because of a corrupt
download but rather that the artifact cannot be processed even when it
is correctly downloaded, p2 shouldn't be trying to download it again
200 times. A library I imagine can handle that much more easily. I
don't know that this can be handled using the pack200 executable, and
I'm not suggesting you should aim to provide a native executable;
that's just too much work that doesn't seem necessary.
Regards,
Ed
On 27.06.2018 14:14, Peter Firmstone wrote:
Hi Ed,
So what you want is an executable with a C like return status,
different codes provide failure cause meanings?
Regards,
Peter.
On 27/06/2018 5:46 PM, Ed Merks wrote:
Peter,
I think the key point is that the loop itself doesn't see a status
result that suggests a retry makes sense. I think the invocation of
the pack200 executable doesn't provide the necessary feedback, but
it's been more than a year since I've looked closely at all this.
Regards,
Ed
On 27.06.2018 09:25, Peter Firmstone wrote:
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
_______________________________________________
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
