Community
Participate
Working Groups
Not sure why, but there's many comparator errors in latest I build, indicating bundles need to be retagged, to get latest byte codes. http://build.eclipse.org/webtools/committers/wtp-R3.3.0-I/20110324075937/I-3.3.0-20110324075937/testResults/comparatorUnexpectedMessages.log.txt Unknown at this point if this is due to some "unharmful" change, accidental compiler flag change, or if some static constant changed. If the later, then current "delivered" code would be invalid.
What I've learned so far ... we did switch to new compiler, in I-build. For M6, we used "base builder", which included the JDT compiler marked Eclipse Compiler for Java(TM) Version: 0.B37, 3.7.0 M6 Now, for post M6, we no longer use base builder, but directly use the Eclipse SDK, and incidentally moved to M6, and thus moved to the compiler build 42 ... or, more exactly, the one marked Eclipse Compiler for Java(TM) Version: 0.B42, 3.7.0 M6
Updated for newly-detected dead code block in org.eclipse.wst.common.snippets.
FWIW, the slightly more persistent URL for these comparator warnings, after promoting weekly build, is http://download.eclipse.org/webtools/downloads/drops/R3.3.0/I-3.3.0-20110324075937/testResults/comparatorUnexpectedMessages.log.txt
I've investigated several cases in detail, and all I've looked at had to do with redundant null checks being optimized out (or left in) the resultant byte codes. I think most of this work in JDT compiler was described in bug 326950. I don't plan on doing any additional detailed analysis and will encourage everyone to a) at least re-tag the listed bundles, to make sure their qualifier increases, and b) set "redundant null checks" to error, so can fix source where desired, and c) set "dead code" to error, so can fix/improve some cases. I think most projects could have "redundant null checks" and "dead code" set to error as part of project settings, but some may want to leave as 'warning', such as if lots of "intentional" dead code. = = = = = JemProjectUtilities unnecessary null check is optimized out opened bug 341367 (but, by chance, discovered bug 341353 which is more important to fix) FacetsPropertyPage unnecessary null check is optimized out opened bug 341376 org.eclipse.jst.ws.axis.consumption.core unnecessary null check is ?left in?, in both classes Java2WSDLCommand WSDL2JavaCommand This all involve a check for null input stream, in statements such as finStream = new FileInputStream(tempOutputWsdlFile); if(finStream != null) { ... But in this case, I think the "new" compiler leaves in the null checks, instead of optimizing it out ... unless I got my files confused. XDocletBuilder unnecessary null check is ?left in? Looking at bytes codes, this one more confusing than most, since a lot of code is, apparently intentionally, "omitted" by some 'if' statements, such it has an if (performValidateEdit) where performValidateEdit is a final static set to false. This makes the "before/after" byte codes even more confusing ... such as ends up with something like IStatus status = null; if (status == null || status.isOk) ... which makes little sense ... but, would take some effort to clean up and support. For this reason, I suggest this one just be re-tagged, unless someone really wants to go and clean up the code? I'm assuming other cases are similar, where the changes in byte codes "don't really matter", but for purposes of long term maintenance, etc., would be best to (at least) re-tag, so our deliverables match latest compiler output.
Adding you to CC, Olivier, just in case you are interested in many "real life" cases. No action required.
The following are latest list of bundles that should be retagged so qualifier increases: org.eclipse.jem.workbench,2.0.300.v200910290230 org.eclipse.wst.common.project.facet.ui,1.4.200.v201101240054 org.eclipse.jst.ws.axis.consumption.core,1.0.406.v201004211805 org.eclipse.jst.ws.axis.creation.ui,1.0.700.v201010181550 org.eclipse.jst.jsf.facesconfig,1.2.1.v20100906 org.eclipse.wst.wsi,1.0.400.v201004220210 org.eclipse.jst.common.ui,1.0.100.v201101101900 org.eclipse.jst.ws,1.0.507.v201004211805 org.eclipse.wst.wsdl.validation,1.1.501.v201004201506 org.eclipse.wst.wsi.ui,1.0.501.v201004201506 org.eclipse.wst.xsd.core,1.1.600.v201011122042 org.eclipse.jst.ws.jaxrs.ui,1.0.400.v201012031836 org.eclipse.jst.j2ee.ejb.annotations.xdoclet,1.2.100.v201003112036
(In reply to comment #6) > The following are latest list of bundles that should be retagged so qualifier > increases: > Should have said "at least" re-tagged. In some cases, source code could probably be improved, as well, if "redundant null checks" or "dead code" turned to "errors" and fixed.
I've fixed org.eclipse.jem.workbench, and org.eclipse.jst.j2ee.ejb.annotations.xdoclet (Note, there is no "maintenance" branch for xdoclet bundle, but I left "as is". since didn't make a code, change, just incremented service field and retagged, so 3.3 version will be district, since byte codes different). That leaves, org.eclipse.wst.common.project.facet.ui,1.4.200.v201101240054 org.eclipse.jst.ws.axis.consumption.core,1.0.406.v201004211805 org.eclipse.jst.ws.axis.creation.ui,1.0.700.v201010181550 org.eclipse.jst.jsf.facesconfig,1.2.1.v20100906 org.eclipse.wst.wsi,1.0.400.v201004220210 org.eclipse.jst.common.ui,1.0.100.v201101101900 org.eclipse.jst.ws,1.0.507.v201004211805 org.eclipse.wst.wsdl.validation,1.1.501.v201004201506 org.eclipse.wst.wsi.ui,1.0.501.v201004201506 org.eclipse.wst.xsd.core,1.1.600.v201011122042 org.eclipse.jst.ws.jaxrs.ui,1.0.400.v201012031836
Looks like the defaults are: Redundant null check: Ignore Dead code (e.g. "if (false)"): Warning
The following have been retagged for the 3.3 build: org.eclipse.jst.ws.axis.consumption.core org.eclipse.jst.ws.axis.creation.ui org.eclipse.wst.wsi org.eclipse.jst.ws org.eclipse.wst.wsdl.validation org.eclipse.wst.wsi.ui org.eclipse.wst.xsd.core org.eclipse.jst.ws.jaxrs.ui
There's only a few of these left to tag. I'll do org.eclipse.jst.common.ui
Appears org.eclipse.jst.common.ui has already had a service field increment in HEAD (vs. R3_3_maintenance) so I literally just retagged. That leaves only org.eclipse.jst.jsf.facesconfig (There is another showing up in comparator logs, but for different reasons, and there's another bug open for that: bug 344207.
Raghu, Can you re-tag org.eclipse.jst.jsf.facesconfig so we can get this one closed? (Or, if there's some reason you don't want to, let me know that too).
(In reply to comment #13) > Raghu, > > Can you re-tag > org.eclipse.jst.jsf.facesconfig > > so we can get this one closed? > > (Or, if there's some reason you don't want to, let me know that too). For re-tagging, don't I need to increment the service version too to avoid version errors?
(In reply to comment #14) > (In reply to comment #13) > > Raghu, > > > > Can you re-tag > > org.eclipse.jst.jsf.facesconfig > > > > so we can get this one closed? > > > > (Or, if there's some reason you don't want to, let me know that too). > > For re-tagging, don't I need to increment the service version too to avoid > version errors? Yes. This could be a reason why some people would prefer not to retag, and continue to use the old version, compiled by the old compiler, but ... to me it seems cleaner and easier to maintain to be "current".
Released fix for org.eclipse.jst.jsf.facesconfig
fixed
