Description David Williams 2011-01-09 23:54:08 EST

related to bug 333678 ... 

The class has many unused variables, it seems. There are (as far as I can see from decompiling the byte codes) 3 of them that are now correctly detected by new JDT compiler, and removed from byte codes. Hence making the bits different, even though version and qualifier are the same. 

The three are

relevence in  public void acceptPackage(char[] packageName);

staticsOnly in   private void findFieldsAndMethodsFromMissingFieldType(char[] token, org.eclipse.wst.jsdt.internal.compiler.lookup.Scope scope, org.eclipse.wst.jsdt.internal.compiler.lookup.InvocationSite invocationSite, boolean insideTypeAnnotation);

staticsOnly in   private void findFieldsAndMethodsFromMissingReturnType(char[] token, org.eclipse.wst.jsdt.internal.compiler.lookup.TypeBinding[] arguments, org.eclipse.wst.jsdt.internal.compiler.lookup.Scope scope, org.eclipse.wst.jsdt.internal.compiler.lookup.InvocationSite invocationSite, boolean insideTypeAnnotation);

If it is desired to leave this bundle the same in maintenance stream and head, then the variables would have to be fixed/removed from source. 

The reason there were not (correctly) detected as unused before is that they are involved, at some point, in some computation ... and those computations might have side effects ... so can not just blindly remove every line they are used. For example, in acceptPackage, we have 

int relevance = computeBaseRelevance();
relevance += computeRelevanceForResolution();
relevance += computeRelevanceForInterestingProposal();

which blindly could only be reduced to 

computeRelevanceForResolution();
computeRelevanceForInterestingProposal();

So ... not sure what to advise ... ideally you could clean up the code?  [Tip: eclipse37M4 will correctly show the variables unused ... previous versions won't]

If you really wanted, I could fix our releng test to ignore this difference in byte codes produced by the compiler ... but seems like a bad idea long term, since then might miss more important errors/changes in the future ... as well as risk having different bits "in the wild" that have same version/qualifier.