| Summary: | [JarProcessor] Executable limitations | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Chris Aniszczyk <caniszczyk> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | andrew_cornwall, aniefer, berthold_lebert, Ed.Merks, pascal, robbinsj |
| Version: | 3.4 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Chris Aniszczyk
I would like to see unpack use a class and stop launching an unpack200 executable. For packing, launching the executable is fine. The jar processor now lives in p2. The reason why the executable is invoked is because the call to the java class results in leaks, but more power to you :-) (In reply to comment #3) > The reason why the executable is invoked is because the call to the java class > results in leaks, but more power to you :-) > Oh, why are there memory leaks? Is there an issue open against Sun? Is "because it is poorly implemented" a good enough answer? Andrew was the main investigator behind this, but I recall seeing data structures with static fields accumulating data. I don't know if a bug had been opened against Sun. Also note that since late last week end, Harmony has an initial implementation for unpack200 however I don't know its level of completeness or robustness. The problem was from internal static structures that grew with each bundle that was packed/conditioned. After packing something like say 20 bundles then we ran out of memory. We did not open anything at Sun. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. Apparently this will go away in Java 14 at which point this whole issue needs to be revisited anyway (if anyone is paying attention). |