Hi Pascal As Mickael already mentioned, most of this has already been discussed on this list. The JEP itself explains why it got deprecated.
Dani From: Mickael Istria <mist...@redhat.com> To: P2 developer discussions <p2-dev@eclipse.org> Cc: Daniel Megert <daniel_meg...@ch.ibm.com> Date: 19.07.2018 10:49 Subject: Re: [p2-dev] FYI: Fw: New candidate JEP: 336: Deprecate the Pack200 Tools and API Hi, 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 maintenance. - 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. Cheers,
_______________________________________________ p2-dev mailing list p2-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/p2-dev
