Why not using commons compress (
http://commons.apache.org/proper/commons-compress/pack200.html) ?
ᐧ

On Thu, Jun 28, 2018 at 1:41 PM Mikaël Barbero <
[email protected]> wrote:

> As far as I understand from
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001472.html, you
> don't necessarily need to start with Harmony implementation as there
> already is a full (read pack and unpack) Java implementation of pack200.
> http://hg.openjdk.java.net/jdk/jdk/file/2f2af62dfac7/src/java.base/share/classes/com/sun/java/util/jar/pack
>
> So I guess that one proposal to JEP336 could be: deprecate the c++ native
> implementation (as this is not used anymore for the JRE) but keep the spec
> + Java impl.
>
> Then anyone (Peter?) could sign up to maintain it @ openjdk.
>
> WDYT?
>
> *Mikaël Barbero *
> *Team Lead - Release Engineering | Eclipse Foundation*
> 📱 (+33) 642 028 039 | 🐦 @mikbarbero
> Eclipse Foundation <http://www.eclipse.org/>: The Platform for Open
> Innovation and Collaboration
>
> Le 28 juin 2018 à 13:26, Peter Firmstone <[email protected]> a
> écrit :
>
> I'm not currently a committer, though happy to, if invited. :)
>
> To sum up:
>
>  1. The Pack200 clean room implementation written in Java, it can
>     compress and decompress java bytecode and pack.gz files, it was a
>     module developed as part of Apache Harmony, AL2 licensed.
>  2. Oracle owns the Pack200 Standard copyright.
> https://docs.oracle.com/javase/10/docs/specs/pack-spec.html
>  3. OpenJDK's Pack200 test compatibility kit, is GPL2 with classpath
>     exception, (I haven't gone down this road yet, but it's ideal for
>     testing compatibility, with some modification for the libraries
>     different api).
>  4. We won't be implementing any of the Java API's copyrighted by Oracle.
>
> Oracle is deprecating the Pack200 standard and its GPL2 licensed
> implementation.
>
> https://docs.oracle.com/javase/10/docs/legal/copyright.html
>
> Thanks,
>
> Peter.
>
> On 28/06/2018 8:54 PM, Mickael Istria wrote:
>
>
>
> On Thu, Jun 28, 2018 at 12:52 PM, Daniel Megert <[email protected]
> <mailto:[email protected] <[email protected]>>> wrote:
>
>    > @Daniel: would you mind contacting EMO Legal asking them about
>    this and sharing the answer here?
>
>    Peter should do that as he knows better what he's exactly doing
>    ;-). Also, I will be away next week and fully booked today.
>
>
> Is Peter a committer on any Eclipse.org project? I'm afraid if he sends
> the request without backup from a committer, it will be rejected as "sorry,
> we only work for Eclipse.org projects, and don't do legal consulting for
> the whole wide world".
>
>
> _______________________________________________
> p2-dev mailing list
> [email protected]
> 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
> [email protected]
> 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
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/p2-dev



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
_______________________________________________
p2-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/p2-dev

Reply via email to