This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
1. Change <makenbm> to convert all *.jar -> *.jar.pack.gz in its fileset, e.g. using <pack200>. 2. Change o.n.updater to recognize and handle *.jar.pack.gz (and perhaps *.jar.pack) automatically, e.g. using java.util.jar.Pack200. Compression savings on JAR files containing mostly classes can be substantial. This would be relatively easy, pretty transparent, and could make NBMs much smaller.
*** Issue 104483 has been marked as a duplicate of this issue. ***
Added issues@nbbuild to Cc. I would say this should be done in coordination with build engineering. Before implementation in build system, please count with extreme memory leaks in pack200 (explicitly trash&gc pack200 instance very often).
It's not in our plans for a long time. IMHO I should close as WONTFIX.
No? Seems to me like it would substantially decrease download time in most cases.
Being talked about again.
*** Bug 178292 has been marked as a duplicate of this bug. ***
Let's assume we can do this for 6.9. We need a plan. I've composed http://wiki.netbeans.org/FitnessForNBMs based on the ideas found in this bug and bug 178292. Please look at the page and modify it to properly estimate the amount of necessary work. Thanks.
I've updated the page to reflect your comments. Let's do one more round of review. Thanks.
Created attachment 93798 [details] Patch to fix the issue Calling for review. repository: http://hg.netbeans.org/prototypes/ branch: nbms-pack200-84852 Feel free to make changes directly to the branch or leave comments here. Notes: 1) It looks like memory leak is unpack200, not in pack200 so I used java API for Pack200 in MakeNBM. The leak is native code and I find no way to release memory that it uses. That`s why I used separate process - <javahome>/bin/unpack200 - to unpack the .pack.gz in AutoUpdate task and autoupdate.services. 2) There is no jar verification after it is packed at this moment. Cases when it is broken are rare so probably it is easier to mention such jars using pack200.excludes property than do verification for every packed jar which is rather time consuming operation.
Quite nice. I have not found a problem from my perspective. Just: Y01 We shall make sure the pack200 leak is reported to JDK team and properly escalated
Re Y01: Marek Slama has filed it about 3 years ago http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6531345 Not sure about escalation.
> Y01 We shall make sure the pack200 leak is reported to JDK team > and properly escalated I pinged the owners of #6531345 with a question about possibility of having a fix in an update of JDK 6. Will see what they reply.
(In reply to comment #9) > repository: http://hg.netbeans.org/prototypes/ > branch: nbms-pack200-84852 > > Feel free to make changes directly to the branch prototypes #f4ceb8444fb1 prototypes #c1dbe6851cb7 prototypes #99f66b7ea1ee prototypes #20a94046c5f8
Thanks everybody, merged to core-main.