Community
Participate
Working Groups
What component is for jarProcessor bugs? Please redirect as appropriate. After several of us wasted several days chasing down a corrupt class file problem caused by pack200 (bug 232588), I'm opening this bug against the jarProcessor, questioning why on earth isn't -E4 the default (for jarProcessor's use of pack200). Sure, I know it's not your bug, but pack200's, and I know you've provided some nice examples of how to specify -E4 as the default, and I know that bug 232588 was ultimately a bug in our WTP scripts, but I wouldn't have even needed those scripts if -E4 was the automatic default that we (eclipse projects) impose on pack200. It would seem that would _always_ be the right thing to do! I'm categorizing this as a critical bug, instead of a mere enhancement request, since the consequences of not using -E4 are quite bad (corrupt class files are, after all "lost data"!), hard to find when occurs, and can "appear suddenly" even when previous builds are fine. You could still honor pack.properties, etc., if someone wanted to force it back to the E5 level, but there is no reason we should let this hole live on. I wonder how many other ganymede projects do not use -E4 and are in danger of "suddenly" (if accidentally) introducing corrupt class files that might not even show up until after release. Now that this problem as existed for over a year, we in Eclipse really should make our "common build tools" as robust and easy to use as possible.
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.
