Community
Participate
Working Groups
Build Identifier: I20110613-1736 When a package-info file contains import statements and the organize imports is set to run as a save action, saving some other file in that package sometimes inserts the package-info's import statement(s) in random locations, thus corrupting the saved source code. This does not happen consistently, so indicates a race condition. Workarounds: (1) Use fully-qualified names in package-info.java (no imports). (2) Disable "organize imports" as a save action. Reproducible: Sometimes Steps to Reproduce: Given a Java project with the following files, turn on organize imports as a save action (Project -> Properties -> Java Editor -> Save Actions -> Enable project specific settings -> Perform the selected actions on save -> Organize imports). === annot/Nullable.java ================================================ package annot; import java.lang.annotation.Documented; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; @Documented @Retention(RetentionPolicy.RUNTIME) public @interface Nullable { } === sample/package-info.java =========================================== @Nullable package sample; import annot.Nullable; === sample/Thing.java ================================================== /* * This is a large copyright statement. * This is a large copyright statement. * This is a large copyright statement. * This is a large copyright statement. * This is a large copyright statement. * This is a large copyright statement. */ package sample; public class Thing { public class Other { } } ======================================================================== Now when saving Thing.java, the copyright statement is sometimes corrupted to look like this: /* * This is a large copyimport annot.Nullable; is is a large copyright statement. * This is a large copyright statement. * This is a large copyright statement. * This is a large copyright statement. * This is a large copyright statement. */ package sample; That is, the import statement from package-info.java overwrites some of the first characters in the file for all files in that package. This does not occur on every save, suggesting a race condition. For me, it happens very reliably when I make an edit and then hit Ctrl-S immediately afterward (within half a second). When there is no large copyright statement, it's even worse -- actual program code is overwritten, or for very short files (like Thing.java with comments removed) I get an ArrayIndexOutOfBounds exception during save (error info to be attached to the bug report in a moment).
Created attachment 201923 [details] Error log when saving a comments-removed Thing.java
Additional workaround: (3) When this occurs, hit "Ctrl-Z" to undo the save actions.
Are you sure "organize imports" is your only action on save ? So far, I cannot reproduce.
Created attachment 201939 [details] tar.gz of workspace Yes, I'm pretty sure this is my only save action. Here's a zip-up of the workspace, for others to check that I didn't miss anything.
For your information, I have also encountered this bug (Eclipse Indigo / Windows XP) on two different files. Note that : - undoing the changes and saving again causes the same corruption in the same place - modifying the text of the javadoc/copyright statement in package-info.java moves the insertion point of the insert statements by the same amount in the corrupted file. If the import statement starts about 1000 character after the start of the package-info file, this same import statement is inserted at approximately 1000 characters after the start of the saved file. It seems that somehow Organize Imports is confusing two files.
I think this is a side-effect of what has been found in bug 348024 (see bug 348024 comment 20). If you can reproduce with 3.7.1RC2, it would be good to know. I believe the AST used to compute the organize import operation ends up being the one for the package-info file.
(In reply to comment #6) > If you can reproduce with 3.7.1RC2, it would be good to know. I'm sorry to say I probably won't be able to test this anytime soon. But just in case, can you tell me how to get 3.7.1RC2 ?
(In reply to comment #7) > I'm sorry to say I probably won't be able to test this anytime soon. But just > in case, can you tell me how to get 3.7.1RC2 ? It is not available yet. RC2 build occurred today. I could reproduce the issue using 3.7.0. I am testing latest 3.7 build.
I am closing as a duplicate of bug 348024 as I cannot reproduce once the fix for bug 348024 is applied. I can reproduce without it. *** This bug has been marked as a duplicate of bug 348024 ***
Verified for 3.7.1 RC2 using build I20110824-0800.
Verified for 3.8M2