[Building Sakai] javac giving different binary size based on order of source files passed

[Gross,Christopher]

Hello!

We recently noticed an issue where samigo wasn't working after a new build.  The problem was that we had not changed samigo at all.  We discovered that GradingService.class in the "broken" samigo suddenly had a slightly smaller file size than the previous version despite the java file it came, as well as the tool and the tool's dependencies, not changing at all.  This was a few weeks ago.  Today I went a little further and had maven give me a debug output of a build of both local branches in question and then used diff to compare them.  I found that, amongst some minor differences that have no effect, there was differences in the arguments being passed to javac by maven.  This difference was only in the order of the source files, so I took the compile line from the working samigo code and simply changed the paths in the line to match the path to the non-working samigo code and then ran javac with those arguments.  The result was the once smaller sized GradingService.class was now exactly the same as the working version.

I did some digging with this in mind and found a few things:

http://stackoverflow.com/questions/9895463/java-assembled-binary-varies-depending-of-the-order-of-the-source-files
http://stackoverflow.com/questions/9505857/workaround-for-javac-compilation-order-bug-in-maven
http://bugs.sun.com/view_bug.do?bug_id=6199662


None of them really help in preventing this from happening in a project as large as Sakai.  In fact, I have since found several other class files that are a different size than previously despite no change in the code.  The bug report was for 1.5 and it was supposedly fixed in 1.6, however we have been compiling with 1.7 for several months now and did still see this issue with 1.6 versions while trying to find the cause.

Has anyone ever seen something like this?  I'm not quite sure how to replicate it because, as I mentioned, the code being compiled is identical but just two copies of it in different locations on disk.

To sum it up in an example: We have two branches in locations A and B on disk.  Currently, branch A is compiling and has the "working" file size for GradingService.class and Samigo functions as expected in Sakai but branch B, despite still compiling without error or warning, has a smaller file size for GradingService.class and visible problems in Sakai.  Now, if we check out a fresh copy of both branches there is a either chance that it will be branch A that now has the problem, that neither has the problem, or that both have the problem.  I have not been able to link this to a specific version of Java at all, just that once a checkout is made to a location on disk and that location compiles incorrectly then that location will always compile incorrectly.

--
Chris Gross
Univerity of Florida
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20121121/d0632193/attachment.html