Bugzilla – Full Text Bug Listing
| Summary: | [jarprocessor] -E4 should be the default parameter for jarProcess's use of pack200 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | David Williams <david_williams> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P4 | CC: | kim.moir, pascal, philippe_mulet |
| Version: | 3.4 | ||
| Target Milestone: | 4.0 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
David Williams
The jar processor is owned by p2 Lowering down the severity and marking as 3.5 because this is not something that we should do now as we don't know what will happen when we will change this. (In reply to comment #2) > Lowering down the severity ... > Why? Because you don't think "corrupt class files" are all that bad?! > ... because this is not something > that we should do now as we don't know what will happen when we will change > this. I agree, but, that doesn't lesson the severity! Perhaps the priority. >Why?
Because it makes Philippe nervous <g>.
Well, it only makes me nervous if we have untriaged blocker/critical issues. It could remain critical for 3.5 if all party agree. This is fine for me. I would hope a blocker to be targeting 3.4.1 if really it is such. I still think "critical" is more accurate, and that _something_ should be done in maintenance stream if possible, with perhaps the default changed in 3.5 (and, even if done for 3.5, should be done very early in cycle, so unintended side effects could be flushed out). Perhaps "changing the default" is too much of a change for maintenance stream, but perhaps some improved warning messages could be included so people are more aware they are taking a huge risk, if -E4 is not being used. Another possibility for maintenance release is to make a "stand alone" ant task what would check all the produced jars (say, on Ganymede) ... but, seems easier to tweak the jarProcessor, since it has all the info right there already, I would think. I'll feel silly if everyone already is using -E4, but if they are not, then some very bad, very subtle, hard to find bugs can be introduced in maintenance release just by the bad luck of re-compiling some code that produces the right pattern to hit the VM/pack200 bug. Andrew, if this is an easy fix, then we should address it soon, otherwise please clear the milestone. I think it is too late for such a change Moving to inbox Unsetting old milestones Not sure it matters, since this is so old and no one seems to care and anyone who does care has adjusted, but I did some experiments on "Orbit Bundles" with newest pack/unpack200 from Oracle JRE 1.8, against "old bundles" (i.e. old class files at 1.5 or even 1.4 level) and it seems that -E4 is still the best option. With -E4 set, I'd get about 20 "bad bundles" (out of 1500 or so) I tried with -E3 thinking there might be less, but there were actually more! (about 80 or 100) ... and then tried with -E5 (the default) and -E6 and still about 100 or 120 bad bundles [Bad, meaning they would not unpack and jarsigner -verify without error). Not sure what's so special about -E4 .. and, of course, may be strongly related to the "input" class format or byte codes of 1.5 or less. 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. -- The automated Eclipse Genie. This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. |