Community
Participate
Working Groups
Build Identifier: I361I20100809_20100810_0905 To show these results I create a JUnit that open and closes 5 times the same project, Java, SCA, and Dynamic Web Project. I am getting a regression when I execute this code with I361I20100809_20100810_0905 vs I3424I20100312_20100312_1106 In order to wait for the Java Indexer I create a method that get the Job, and wait in a looop until it finishes to continue with the main execution. --------------------------------- For a Java Project init (create an empty project, then copy the content of a project with one class into it) then close the project After Open 1 Time:6078 Closed 1 After Open 2 Time:9469 Closed 2 After Open 3 Time:9156 Closed 3 After Open 4 Time:9078 Closed 4 After Open 5 Time:8063 Closed 5 --------------------------------- For an SCA Project init (create an empty project, then copy the content of a project with a few files into it) then close the project After Open 1 Time:2015 Closed 1 After Open 2 Time:10594 Closed 2 After Open 3 Time:10078 Closed 3 After Open 4 Time:9359 Closed 4 After Open 5 Time:9094 Closed 5 -------------------------------- The Dynamic Web Project does not show much Java Indexer Activity, means less than 1 second or none at all. When I run the same code against this build I3424I20100312_20100312_1106 here are the results: -------------------------------- For a Java Project init (create an empty project, then copy the content of a project with one class into it) then close the project After Open 1 Time:4078 Closed 1 After Open 2 Time:4015 Closed 2 After Open 3 Time:4016 Closed 3 After Open 4 Time:4016 Closed 4 After Open 5 Time:4015 Closed 5 --------------------------------- For an SCA Project init (create an empty project, then copy the content of a project with a few files into it) then close the project After Open 1 Time:4141 Closed 1 After Open 2 Time:4062 Closed 2 After Open 3 Time:4015 Closed 3 After Open 4 Time:4015 Closed 4 After Open 5 Time:4125 Closed 5 -------------------------------- For a Dynamic Web Project init (create an empty project, then copy the content of an empty project into it) then close the project After Open 1 Time:4079 Closed 1 After Open 2 Time:4031 Closed 2 After Open 3 Time:4031 Closed 3 After Open 4 Time:4015 Closed 4 After Open 5 Time:4015 Closed 5 Reproducible: Always Steps to Reproduce: 1.- Create a Java project 2.- Close it (using the IProject.close(monitor) method) 3.- Open it again (using the IProject.open(monitor) method)
I361I20100809_20100810_0905 and I3424I20100312_20100312_1106 are not Eclipse build ID... So, it makes a little bit difficult to really know which build you're using for your tests. Could you retrieve the real Eclipse build ID, they should be found in the Help -> About Eclipse SDK menu item... You should get something like: - Version 3.5.2: Build id: M20100211-1343 - Version 3.6.0: Build id: I20100608-0911 - Version: 3.7.0 Build id: I20100805-1700 Note also that JDT/Core have 2 performance tests for the indexing: one is indexing the entire workspace made of 63 Eclipse projects and another one is indexing only one project. None of these tests shows any significant regression neither for 3.6.0 (vs 3.5.0) nor for 3.7M1 (vs.3.6.0). So maybe there's something specific in your setup which makes the indexer slower, but we definitely need more precise information to have a chance to figure out what happens there... Satyam, please follow-up when required information will be provided, thanks
Please also provide the JUnit test case you used to get the numbers, thanks
This regression is in 3.6.1 (vs.3.4.2) and the only scenario where I can see the regression is when you open a project that is closed, if you import a project the Java indexer takes about the same time in 3.6.1 and 3.4.2. Do you know how can I disable the Java Indexer?
I will provide the JUnit shortly...
Created attachment 177544 [details] Java Indexer Performance Test Here is the plug in I use to get those numbers, fell free to play with the code ;) To run this one just import into eclipse and then right click into the OpenCloseProject.java then runAs -> JUnit Plugin test
(In reply to comment #3) > This regression is in 3.6.1 (vs.3.4.2) and the only scenario where I can see > the regression is when you open a project that is closed, if you import a > project the Java indexer takes about the same time in 3.6.1 and 3.4.2. > Is it 3.6.0 or the last maintenance build? 3.6.1 is not available yet, so, I'm still trying to figure out what build to use to compare with 3.4.2... Saying that, it's a fact that we currently do not test this peculiar scenario (i.e. measure indexing perf after having opened a project). But, from the indexer point of view there's no difference between importing or opening a project. The work done by it in both cases is the definitely the same. So, I strongly suspect that some other work is done while opening the project which slows the indexer in this peculiar case... Do you use a pure Eclipse install to get your number while running your JUnit test or do you have any other plugins (I guess you should have some as one of your test was to open a Dynamic Web Project...). Could let us know what is your exact installation on which you observed this regression? Maybe you can monitor the JUnit test execution using Yourkit and see what's the difference between the two versions. That can easily show us what's slowing down the indexing in 3.6.0 which was not there in 3.4.2... > Do you know how can I disable the Java Indexer? Unfortunately (for you), you can't. Without indexing, several key tools will not work (Search, Code Assist, Open Type, Refactoring, etc.), that's why it's not an option to start the Java Indexer or not...
(In reply to comment #6) > (In reply to comment #3) > > This regression is in 3.6.1 (vs.3.4.2) and the only scenario where I can see > > the regression is when you open a project that is closed, if you import a > > project the Java indexer takes about the same time in 3.6.1 and 3.4.2. > > > Is it 3.6.0 or the last maintenance build? 3.6.1 is not available yet, so, I'm > still trying to figure out what build to use to compare with 3.4.2... OK I just download a couple of Eclipse offerings where I was able to reproduce the problem (I guess any 3.4.2 vs any 3.5.x or 3.6.x will show the regression) Eclipse 3.4.2 Build id: M20090211-1700 vs Eclipse 3.5.2 Build id: M20100211-1343 > Saying that, it's a fact that we currently do not test this peculiar scenario > (i.e. measure indexing perf after having opened a project). But, from the > indexer point of view there's no difference between importing or opening a > project. The work done by it in both cases is the definitely the same. So, I > strongly suspect that some other work is done while opening the project which > slows the indexer in this peculiar case... For 3.5.x and newer versions that is correct, but in 3.4.2 if you import the project it will take (let's say) 8 seconds, and every time you open the project the java indexer will take 2 or 3 seconds to finish, and is a consistent behavior in 3.4.2. In 3.5.x and newer versions, it happens as you say, if we use the same machine and the same code, it will take the 8 seconds to run the Java indexer either when we open the project or when we import the project > Do you use a pure Eclipse install to get your number while running your JUnit > test or do you have any other plugins (I guess you should have some as one of > your test was to open a Dynamic Web Project...). Could let us know what is your > exact installation on which you observed this regression? > This is reproducible in an empty Eclipse workspace, I just verify it with the versions I just mention. BTW when you import the project you just have to import the JavaIndexerPerfTest, and I think I forgot to delete the import package declaration for org.eclipse.perfmsr.core in the MANIFEST.MF you can delete it as well. > Maybe you can monitor the JUnit test execution using Yourkit and see what's the > difference between the two versions. That can easily show us what's slowing > down the indexing in 3.6.0 which was not there in 3.4.2... > > > Do you know how can I disable the Java Indexer? > > Unfortunately (for you), you can't. Without indexing, several key tools will > not work (Search, Code Assist, Open Type, Refactoring, etc.), that's why it's > not an option to start the Java Indexer or not... Not even for testing proposals? a way to crash the JavaIndexer will be good I think :S
As part of fix for bug 250083, the index files are deleted when a project is closed. This explains the difference in times. The index files probably need not be deleted when the project is closed. It does make sense to delete when the project is deleted, but may be the index files can be kept around when the project is closed. Frederic, what do you think?
> The index files probably need not be deleted when the project is closed. The world may have changed completely so I guess it's best to remove the index and rebuild it later. But Frédéric might know a smarter way.
For a project, the index file of the project itself has to be rebuilt each time the project is opened or imported. Hence this index file can be deleted both when the project is closed and/removed. For the index files of the external jar, it's different. The management of those external files are made separately by the Java Model Manager and their corresponding index file life depends whether the external Jar file is still referenced by a project classpath in the workspace or not. This rule is already applied both when the project is closed or removed. I agree with Satyam's proposal in comment 8 that when a project is only closed, we could think that it will be reopened at some time in the future. Hence, it could be interesting in this case not to delete the index files of the external jar to avoid a re-indexing when that will arrived... Dani, if we do not delete the index file and the external jar change when the project is closed, then it will be re-indexed by the IndexManager as it is still referenced in the index locations table. The only disadvantage of this fix, is that it will consume a little bit more disk space when the project is closed as index files remain on disk. But I think it is an acceptable compromise to avoid this performance regression... Note also that this performance regression only occurs when the closed project is the last one having a dependency on the external jar file. If several projects have the same dependency on an external jar file, closing one project does not remove the index file of the jar. I guess this is why nobody else complains about this regression since 3.5: closing all the projects in its workspace seems not to be a real common use case...
>Dani, if we do not delete the index file and the external jar change when the >project is closed, then it will be re-indexed by the IndexManager as it is >still referenced in the index locations table. >The only disadvantage of this fix, is that it will consume a little bit more >disk space when the project is closed as index files remain on disk Didn't you just say in the paragraph above that it also re-indexes when the JAR changes? Could we only keep the index for external JARs and delete the other stuff?
(In reply to comment #11) > >Dani, if we do not delete the index file and the external jar change when the > >project is closed, then it will be re-indexed by the IndexManager as it is > >still referenced in the index locations table. > > >The only disadvantage of this fix, is that it will consume a little bit more > >disk space when the project is closed as index files remain on disk > Didn't you just say in the paragraph above that it also re-indexes when the JAR > changes? > Yes, that's what I said: the index file remains on disk *and* continue to be updated when the corresponding external file is changed... > Could we only keep the index for external JARs and delete the other stuff? That's what we intend to do: remove the index file of the project and any other its local resources (local jars and class folders) and keep only the index(es) of the external JAR(s)...
>Yes, that's what I said: the index file remains on disk *and* continue to be >updated when the corresponding external file is changed... OK, but then your previous statement is not correct: > >The only disadvantage of this fix, is that it will consume a little bit more > >disk space when the project is closed as index files remain on disk Or did I miss something?
(In reply to comment #13) > >Yes, that's what I said: the index file remains on disk *and* continue to be > >updated when the corresponding external file is changed... > OK, but then your previous statement is not correct: > > > >The only disadvantage of this fix, is that it will consume a little bit more > > >disk space when the project is closed as index files remain on disk > > Or did I miss something? I think you miss (or I wasn't clear enough about) the fact that before the fix for bug 250083, the index file of the external jar file was deleted when the project was closed. With the Satyam's proposal, this will no longer happen. The index of the external jar file will be kept active in this case, hence the corresponding index file will still continue to exist (and consume space) on disk. That's what I said it's a little disadvantage... Hope this is clear now... :-S
>index file will still continue to exist (and consume space) on disk. That's >what I said it's a little disadvantage... Mm, but you also said (and confirmed) this: >Yes, that's what I said: the index file remains on disk *and* continue to be >updated when the corresponding external file is changed... So, isn't that another disadvantage / performance impact?
(In reply to comment #15) > >index file will still continue to exist (and consume space) on disk. That's > >what I said it's a little disadvantage... > Mm, but you also said (and confirmed) this: > >Yes, that's what I said: the index file remains on disk *and* continue to be > >updated when the corresponding external file is changed... > So, isn't that another disadvantage / performance impact? Right, the update will also consume time and might be a performance disadvantage. But, I'm still convinced it's an acceptable compromise. If the user definitely do not want to be annoyed by the indexing of this external jar file, (s)he still can delete the project from the workspace...
> But, I'm still convinced it's an acceptable compromise. Right. I didn't say otherwise ;-) Just wanted to have the facts laid out.
I am working with a RAD version that adopts Eclipse 3.6 and facing somewhat similar issues while creating one of our specific project types. I took some measurements using Yourkit 9.0 and found that Java Indexing takes more time in current RAD based on Eclipse3.6. As per the yourkit measurements, the delay occurs because the very first time Java Indexing takes place for a lot of jar files. Specifically jdt class's AddJarFileToIndex.execute method is invoked for all the jar files contained in the runtime(Local server or Stubs). In this case the runtime stub contains approximately 104 jar files. In latest version of RAD --> AddJarFileToIndex.execute when invoked multiple times took 44% of the total time of the project creation operation. The number of stub jars present were 104. In previous versions --> AddJarFileToIndex.execute when invoked multiple times took 26% oof the total time of the project creation operation. The number of stub jars present were 104. Please let me know if you need the Yourkit snapshots.
Hi As this affects RAD too. So is there any plans to fix this for the eclipse version that is adopted by current version of RAD? Thanks
(In reply to comment #19) > Hi > > As this affects RAD too. So is there any plans to fix this for the eclipse > version that is adopted by current version of RAD? > > Thanks Eclipse does not know of RAD and on which version they ship. You need to ask the product providers what their plans are.
(In reply to comment #18) > > Please let me know if you need the Yourkit snapshots. Yes, the Yourkit snapshots should be useful.
Gauray, I'm not sure it's the same issue you have. Can you please attach the traces as requested by Satyam?
Ayushman, please investigate ideas given by Frédéric in comment 10.
Created attachment 182351 [details] Contains the snapshots related to this bug
(In reply to comment #24) > Created an attachment (id=182351) [details] [diff] > Contains the snapshots related to this bug Ayush, please look at those YourKit snapshots that belong to comment 18 and verify that the problem reported in comment 18 boils down to the same one reported in comment 0.
(In reply to comment #24) > Created an attachment (id=182351) [details] [diff] > Contains the snapshots related to this bug Gaurav, this seems to be a separate issue than the one reported in this bug. Here, the problem occurs in opening and closing the projects when indexes are deleted and rebuilt. In your case, the slowdown is observed while adding all the JARs to the index. Can you please file another bug for this? Thanks
Created attachment 183975 [details] proposed fix v1.0 + regression tests During investigation, I observed that not removing the index of external jar alone wasn't enough. If we modify the jar and re-open the project, it does not get reindexed. So, after discussing possible solutions with Satyam and Frederic, the attached patch with Frederic's suggestion seems to be the best approach here. It does two things - 1) Does not remove the index file when closing the project. 2) Enable reindexing of the file when the timestamp of external jar has changed. (This is done by first removing the index for external jar as soon as change in timestamp is found - DeltaProcessor.createExternalArchiveDelta(HashSet, IProgressMonitor)) All JDT/Core tests pass. Need to tun JDT/UI tests as well.
(In reply to comment #27) > All JDT/Core tests pass. Need to tun JDT/UI tests as well. All JDT/UI tests passed.
Created attachment 184017 [details] proposed fix v1.1 + regression tests + perf test Same fix with minor change in the debug messages of added tests. Also added a performance test. Satyam, please review. Thanks!
I think the time stamps of the external jars should also not be deleted when the project is getting closed. With this patch, I could see that the call to refreshExternalArchives() after the project opens, re-indexes the jar file even if the jar file is not modified. Couple of points with the tests: 1. Does the println's in the test help? They do affect the readability of the test. 2. The performance test should have the line waitUntilIndexesReady() after the project open and before the close.
Created attachment 184170 [details] proposed fix v1.2 + regression tests + perf test Here's the patch incorporating above suggestions.
Couple of minor comments :( 1. As the semantics of (true or false) for this.manager.removePerProjectInfo had changed, the comment that goes along with them should also change. 2. I don't see the need of looping in forgetExternalTimestamps() if the argument is false. This function probably need not be called if the argument is false. 3. I couldn't understand why was touch() modified in AbstractJavaModelTests.java. Is there something I am missing?
Created attachment 184223 [details] proposed fix v1.3 + regression tests + perf test Sorry I didnt scrutinize the patch properly. I was hitting bug 305172 in the tests added here and got distracted. :( New patch takes care of above comments
Frédéric, can you also take a look at the patch? Thanks.
Patch looks good for me.
(In reply to comment #34) > Frédéric, can you also take a look at the patch? Thanks. (In reply to comment #33) > Created an attachment (id=184223) [details] > proposed fix v1.3 + regression tests + perf test > The code changes look good to me. One cosmetic remark though... In JavaModelManager.removePerProjectInfo(Javaproject, boolean), I'd rather prefer see the added test written with braces: if (removeExtJarInfo) { info.forgetExternalTimestampsAndIndexes(); } I know this add one extra line, but IMO, it's a code quality basic rule which can avoid some unintentional errors! If you definitely want to save lines, then it's better to write: if (removeExtJarInfo) { info.forgetExternalTimestampsAndIndexes(); } or if (removeExtJarInfo) info.forgetExternalTimestampsAndIndexes(); I also have some remarks about tests... 1) Regression tests I'm not sure that removing the index of external jar file was necessary in OutputFolderTests.testInvalidOutput() and ThreadSafetyTests.testDeadlock01() tests. They also pass when setting the removeExtJarInfo argument to false... But that's a minor point. 2) Performance test a) the adding test should be put at the end of the test suite. We want to avoid to impact tests results by changing the tests order... b) as we already have a test to measure time to close project, I think this additional test should only measure the time to open projects. In fact that during this operation that the regression was observed, hence it should be enough to limit the measure to this operation. c) note that the existing test testCloseProjects is somehow erratic. I just want you to get some numbers running the added testOpenProjects to see if it can notice the degradation vs 3.4.2 and also the improvement with your patch. It should but if it does not then it's not necessary to add it... At least the verification should be done manually.
(In reply to comment #36) > 1) Regression tests > > I'm not sure that removing the index of external jar file was necessary in > OutputFolderTests.testInvalidOutput() and ThreadSafetyTests.testDeadlock01() > tests. They also pass when setting the removeExtJarInfo argument to false... > But that's a minor point. > I think we should leave this to true so that there is no change with the test.
(In reply to comment #37) > (In reply to comment #36) > > > 1) Regression tests > > > > I'm not sure that removing the index of external jar file was necessary in > > OutputFolderTests.testInvalidOutput() and ThreadSafetyTests.testDeadlock01() > > tests. They also pass when setting the removeExtJarInfo argument to false... > > But that's a minor point. > > > I think we should leave this to true so that there is no change with the test. You're entirely right Satyam (as usual :-))! I was wrongly thinking that the index file was not removed before the fix although it has been since fix for bug 250083... :-S Hence, I agree it's better to set it to true...
Ayushman, please update the patch with latest Frédéric's comments. Once this is done, it should be ready to be released.
Created attachment 184264 [details] Proposed patch perfs test (In reply to comment #36) > > c) note that the existing test testCloseProjects is somehow erratic. I just > want you to get some numbers running the added testOpenProjects to see if it > can notice the degradation vs 3.4.2 and also the improvement with your patch. > It should but if it does not then it's not necessary to add it... At least the > verification should be done manually. First runs are not really encouraging... :-( Using the attached perf test, I get following numbers: 1) With patch ------------- Measures (~Elapsed Process time): - n° 1: 95579ms - n° 2: 118438ms - n° 3: 124953ms - n° 4: 125640ms - n° 5: 128031ms - n° 6: 87219ms - n° 7: 128297ms - n° 8: 73656ms - n° 9: 127500ms - n° 10: 75156ms Test duration = 1084469ms Time average = 108446 2) Without patch ---------------- Measures (~Elapsed Process time): - n° 1: 86892ms - n° 2: 123578ms - n° 3: 86157ms - n° 4: 130469ms - n° 5: 78000ms - n° 6: 155156ms - n° 7: 78203ms - n° 8: 130281ms - n° 9: 76250ms - n° 10: 129922ms Test duration = 1074908ms Time average = 107490 As you can see there's no evidence that the test is able to show the improvement or worst, there's no improvement at all! It's also obvious that there's a high dispersion in the test result (confirming my initial assumption... :-( ) And finally, the test is currently missing all projects reopening, otherwise all following tests will fail due to closed projects! I'll continue my investigation: 1) try to run this test against 3.4.2 2) verify whether there's external jar file reindexing while running this test without patch. If not that would explain that there's no difference between the two runs...
Created attachment 184269 [details] Java Indexer Performance Test The performance test provided by Adrian, after having fixed the way to wait for the end of indexing, confirms that the patch addresses the original issue. Here are the output I got: 1) With the fix: --------------- init Closed init After Open 1 Time:1173 Closed 1 After Open 2 Time:1126 Closed 2 After Open 3 Time:1126 Closed 3 After Open 4 Time:1127 Closed 4 After Open 5 Time:1126 Closed 5 2) Without the fix: ------------------ init Closed init After Open 1 Time:3752 Closed 1 After Open 2 Time:3747 Closed 2 After Open 3 Time:3751 Closed 3 After Open 4 Time:4157 Closed 4 After Open 5 Time:3721 Closed 5 3) With 3.4.2: ------------- init Closed init After Open 1 Time:1126 Closed 1 After Open 2 Time:1079 Closed 2 After Open 3 Time:1079 Closed 3 After Open 4 Time:1079 Closed 4 After Open 5 Time:1079 Closed 5 So, 2 conclusions on this: 1) Those times confirm that with the fix we're back to 3.4.2 performances :-) 2) The additional perf tests does not work
I give +1 for the patch without the performance test. Hence, it's ok for me to release the fix as soon as the perf tests is removed from the patch and another fup bug is opened to fix the problem on this problematic test (as I still believe a perf test will still be a good idea...)
(In reply to comment #41) > Created an attachment (id=184269) [details] > Java Indexer Performance Test > > The performance test provided by Adrian, after having fixed the way to wait for > the end of indexing, confirms that the patch addresses the original issue. > > Here are the output I got: > > 1) With the fix: > --------------- > init > Closed init > After Open 1 Time:1173 > Closed 1 > After Open 2 Time:1126 > Closed 2 > After Open 3 Time:1126 > Closed 3 > After Open 4 Time:1127 > Closed 4 > After Open 5 Time:1126 > Closed 5 > > 2) Without the fix: > ------------------ > init > Closed init > After Open 1 Time:3752 > Closed 1 > After Open 2 Time:3747 > Closed 2 > After Open 3 Time:3751 > Closed 3 > After Open 4 Time:4157 > Closed 4 > After Open 5 Time:3721 > Closed 5 > > 3) With 3.4.2: > ------------- > init > Closed init > After Open 1 Time:1126 > Closed 1 > After Open 2 Time:1079 > Closed 2 > After Open 3 Time:1079 > Closed 3 > After Open 4 Time:1079 > Closed 4 > After Open 5 Time:1079 > Closed 5 > > So, 2 conclusions on this: > 1) Those times confirm that with the fix we're back to 3.4.2 performances :-) > 2) The additional perf tests does not work Kudos!!!! :D
(In reply to comment #40) > Created an attachment (id=184264) [details] [diff] > Proposed patch perfs test Hmm, I had noticed improved numbers running the perf test without the AbstractJavaModelTests.waitForAutoBuild(); Is it necessary/ required here? >And finally, the test is currently missing all projects reopening, otherwise >all following tests will fail due to closed projects! That should be trivial i guess - run another loop to open all projects after getting the numbers. I'll release the patch for now without the perf test then, since with Adrian's project we get the desired improvement. Thanks Frederic!
Taken care of adding curly braces per comment 36. Released in HEAD for 3.7M4. Note to verifier: Use the project in comment 41 to test.
> I'll release the patch for now without the perf test then, since with Adrian's > project we get the desired improvement. Thanks Frederic! Please post the follow-up bug here.
(In reply to comment #46) > > I'll release the patch for now without the perf test then, since with Adrian's > > project we get the desired improvement. Thanks Frederic! > Please post the follow-up bug here. I've created bug 331632 to follow-up work on performance test and attached a draft patch to it.
Verified for 3.7M4 using build id I20101205-2000
Ayush, please prepare and attach a 3.6.2 maintenance branch patch with this tuning & tests. We will want to make this available on 3.6.2.
Created attachment 184772 [details] patch for 3.6.2 I've also added the fix for bug 331770 and the perf test from bug 331632. Dani, need your go ahead for 3.6.2
(In reply to comment #50) > Created an attachment (id=184772) [details] [diff] > patch for 3.6.2 > > I've also added the fix for bug 331770 and the perf test from bug 331632. > > Dani, need your go ahead for 3.6.2 +1 to put it into 3.6.2. Regarding the performance test: this only makes sense if you also backport it to the 'perf_35x' branch. I leave that up to you. Srikanth, please review the 3.6.2 patch.
Patch looks good.
(In reply to comment #52) > Patch looks good. Just figured that for the tests in JavaSearchBugsTest to pass, we also need the fix for bug 305172, since refreshLocal(..) has a bug without the fix. So we either also release fix for 305172 into 3.6.2 or use refreshExternalArchives() instead of refreshLocal(..) here, which however, is an indirect shortcut method of refreshing indexes for external jars. Satyam, what do you think is the best way?
(In reply to comment #53) > Just figured that for the tests in JavaSearchBugsTest to pass, we also need the > fix for bug 305172, since refreshLocal(..) has a bug without the fix. So we > either also release fix for 305172 into 3.6.2 or use refreshExternalArchives() > instead of refreshLocal(..) here, which however, is an indirect shortcut method > of refreshing indexes for external jars. Satyam, what do you think is the best > way? The patch doesn't require bug 305172, but the test may fail otherwise and hence modifying the test is good enough for 3.6.2.
Created attachment 185039 [details] patch for 3.6.2 with slight change This is the same patch using refreshExternalArchives instead of IProject#refreshLocal(..) in JavaSearchBugsTest. All JDT Core tests pass.
.
Released in R3_6_mainainence for 3.6.2.
Verified for 3.6.2 RC2 using build M20110119-0834
