New candidate JEP: 336: Deprecate the Pack200 Tools and API (original) (raw)
Kumar Srinivasan ksrinifmt at gmail.com
Tue Jun 26 13:50:35 UTC 2018
- Previous message: New candidate JEP: 336: Deprecate the Pack200 Tools and API
- Next message: New candidate JEP: 336: Deprecate the Pack200 Tools and API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Peter,
There are two parts to Pack200 (maybe three), what you looked at is unpack200(.exe), a C++ native decoder or the unpacker, this is primarily used by the JDK installers to break the bootstrap, ie. the chicken/egg problem.
FWIW, the complete coder and decoder implementations in Java are available at: http://hg.openjdk.java.net/jdk/jdk/file/2f2af62dfac7/src/java.base/share/classes/com/sun/java/util/jar/pack
Hope this helps.
Regards Kumar Srinivasan
On Wed, Jun 13, 2018 at 9:12 AM Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
Hi Daniel,
I had a look at the pack200 code in openjdk, it's written in c++, and looks a little painful to maintain. I also had a look at Apache Harmony's implementation, written in Java, it uses the ASM byte code library and it's also already an OSGi Bundle. It's still only at bytecode version 1.6, but it's going to be a lot easier to maintain in the long term. https://github.com/pfirmstone/pack200 Cheers, Peter. On 13/06/2018 6:50 AM, Daniel Megert wrote: > pack200 is used by the Eclipse update manager a.k.a. p2. The JARed > plug-ins are compressed with pack200 and put into a p2 repository. > Removing pack200 will make the download (and hence install) of plug-ins > much slower. Eclipse would therefore like to keep this technology. If > that's not an option, then we would like that the removal does not happen > before Java 13. > > Dani > Eclipse PMC >
- Previous message: New candidate JEP: 336: Deprecate the Pack200 Tools and API
- Next message: New candidate JEP: 336: Deprecate the Pack200 Tools and API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]