Re: [p2-dev] Pack200 compression

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

I think it is not
clear whether one is allowed to ship an implementation of a deprecated
and later removed JSR. Mark could not answer that on jdk-dev. Before moving
it to Eclipse it should definitely go by the legal team.

Dani



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

---

It's an independent clean room implementation
of the Pack200 standard.

We're free to implement support up to Java 8 without legal issues, and
we can steer clear of Java api copyright issues by not implementing 
"Java api".

We can pass through unrecognised bytes uncompressed if necessary to 
support later versions bytecode.   The main issue is support of three
additional class pool constants, two for Java 9 and one for Java 11.

I don't think supporting these additional class pool constants is a big
issue legally as the standards intent is to compress java bytecode, and
we'd be implementing support for these three additional class pool 
constants practically identically to how Java 8 and earlier class pool
constants are supported, we're not really breaking it, but it could be
interpreted as embrace and extend.

Ideally, I'd like to get Oracle's permission to implement support for 
these three constants, so we can support Java 11.

Perhaps we just don't call it Pack200 anymore, to support the three 
class pool constants, we can advise in the documentation, that the 
library supports compression and decompression of Pack200, but we may 
need to use a new file extension for anything later than Java 8 and not
refer to it as Pack200.

Regards,

Peter.


On 27/06/2018 11:18 PM, Daniel Megert wrote:
> 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
>
>
>
>
>
> _______________________________________________
> 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