[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] FYI: Fw: New candidate JEP: 336: Deprecate the Pack200 Tools and API
- From: Peter Firmstone <peter.firmstone@xxxxxxxxxxx>
- Date: Sat, 21 Jul 2018 10:55:43 +1000
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:188.8.131.52) Gecko/20120306 Thunderbird/3.1.20
I have been contacted by Mark regarding maintenance of Pack200 and am
awaiting a follow up reply.
Will keep you posted.
On 19/07/2018 7:08 PM, Daniel Megert wrote:
As Mickael already mentioned, most of this has already been discussed
on this list. The JEP itself explains why it got deprecated.
From: Mickael Istria <mistria@xxxxxxxxxx>
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Cc: Daniel Megert <daniel_megert@xxxxxxxxxx>
Date: 19.07.2018 10:49
Subject: Re: [p2-dev] FYI: Fw: New candidate JEP: 336: Deprecate the
Pack200 Tools and API
I'm putting some "guess" as answer here, but it's really not something
that should be relied upon too strongly for decision making ;)
- Do we know why this technology is being deprecated?
According to the discussions we had earlier on this ML or another,
pack200 seems to be very hard to maintain these days. So I guess it's
just deprecated in Java to focus development effort on some other
pieces of Java which seem more profitable and get rid of a piece which
has a high maintenance cost for a very arguable value.
By very arguable value, I mean that in the Java world, pack200 seems
only used by the Eclipse ecosystem as an optimization. That means that
if there is no pack200, everything would still work, just download
server would face a 40%+ load.
Other dependency managers (Maven, Gradle) I'm aware of didn't really
made the effort of optimizing jars for download size sake and it
didn't prevent them to be successful and no-one really complained
about it specifically. So it seems like pack200 optimization is not a
criteria of success for the Java ecosystem and is probably not so
worth keeping alive if the maintenance effort is huge.
- Would it be safe for us to keep our own implementation of pack200
like it has already been explored?
Given that OpenJDK team wants to drop it because it's a PITA to
maintain, and given that it's not a criterion of success and given
that users and extenders usually wants the Platform to focus on other
things (perf, UX, Java support...); I think it would be a risk to
assume we can safely maintain it with our current resources and
simultaneously work on what the ecosystem would like us to work on.
That said, the proposal made earlier of having p2 bound to the Pack200
Java API rather than the binary would be interesting, and if we have
some guarantee a pack200 Java library gets implemented later and
remain sustainable, let's just use it... as long as it's not extra
- Do you know if there will be a replacement technology from the Java
community, if not will there be another recommended technology?
IIRC, some optimizations are implemented in jmod format; but it's not
meant to be used like we use pack200.
p2-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit