Community
Participate
Working Groups
Created attachment 226109 [details] possible patch In bug 356620 support was added in JDT to allow Eclipse-based products to supply pre-built indexes for classpath entries. It is currently not possible to supply pre-built indexes for a JRE container and, in our Eclipse-based product, allowing this would help improve the performance by reducing the time it takes to index our JRE. We have other function that depends on the index being complete so if a user were to invoke our function early then they would have to wait for the indexing to complete. Attached is a patch which provides the necessary update to allow us to supply pre-built indexes for our JRE. There are some minor things like @since and bundle version values that may need to be done. I don't know the correct values you want for these fields. This patch was created against the R3_8_mainteance branch as, I'm assuming, this is what feeds the 4.2 SR2 release and, ultimately, where I'm hoping this can be included (i.e. in some 4.2.x release).
Created attachment 226791 [details] updated patch This is an updated patch with corrected since tags / copyright updates. The patch is a good start, but a couple things come to mind as missing: 1. we should also be able to set the index paths from EE files - see ExecutionEnvironmentDescription 2. we should add a way to the installed JRE UI to set the location, like we do for all other lib location attributes - see VMLibraryBlock
> 2. we should add a way to the installed JRE UI to set the location, like we > do for all other lib location attributes - see VMLibraryBlock The UI discussion for the pre-built indexes (not specific to the JRE) was discussed in bug 364287, but ultimately it was rejected. Maybe this should be revisited if you think it's needed?
Pushed updated patch + EE support + unit tests to master with: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=3b4cd0912c0e166337d78b6cc6f3dc643bf749a4 > ultimately, where I'm hoping this can be included (i.e. in some 4.2.x release) I could put it in 4.2.2+ but there would be no more releases for 4.2.x after 4.2.2. Troy, would 4.2.2+ be ok, or would 4.3 suffice? Also it would be good if you could supply me with an index file (or however they are stored) and an example of how the index is included so I can make some more regression tests for the new support.
(In reply to comment #3) > Pushed updated patch + EE support + unit tests to master with: > > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/ > ?id=3b4cd0912c0e166337d78b6cc6f3dc643bf749a4 > > > ultimately, where I'm hoping this can be included (i.e. in some 4.2.x release) > > I could put it in 4.2.2+ but there would be no more releases for 4.2.x after > 4.2.2. Troy, would 4.2.2+ be ok, or would 4.3 suffice? > Yes, 4.2.2+ would be perfect. Thank you! > Also it would be good if you could supply me with an index file (or however > they are stored) and an example of how the index is included so I can make > some more regression tests for the new support. I'll have a look at your existing testcases and see if I can come up with something to cover this testing... hopefully by end of this week.
(In reply to comment #4) > I'll have a look at your existing testcases and see if I can come up with > something to cover this testing... hopefully by end of this week. Wouldn't you look at *your* testcase so I can make some unit tests that mimic it? :)
Created attachment 227424 [details] possible testcase patch Sorry for the delay... but here's a possible patch that tests the changes for this patch. Let me know if you have any concerns with it, Thanks!
(In reply to comment #6) > Created attachment 227424 [details] > possible testcase patch > > Sorry for the delay... but here's a possible patch that tests the changes > for this patch. Let me know if you have any concerns with it, Thanks! Thanks for the test Troy, I made some slight changes since the Oracle VM also has the javadoc_location classpath attribute that gets added, so originally the test was failing. Pushed tests to master: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=23eac143248c0ae68aa5d8d673def802f5372a4a
I found a problem with the new support: when cloning the library locations for a given VM install, we end up erasing the index location if it has been set. See the JavaRuntime#getLibraryLocations(IVMInstall) API which causes the problem. pushed fix + regression test to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=63ec01831b3e1b65532b49210ffb0a339e5f1667
Pushed backport to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?h=R3_8_maintenance&id=bb55197dda78f35e3203f5fb369d855be59e4407
