Community
Participate
Working Groups
To support the feature described in bug 181026. The API for IVMInstall.getInstallLocation() and setInstallLocation(File) specifies the file returned/set as "the root directory of the install location of this VM". In order to support JREs defined by .ee files, we need to widen the specification to "the root directory of the install location of this VM or file describing this VM". We want to widen the spec to includes files (not just directories). This is a binary compatible API change.
+1 for M7
There's lot's of existing users of IVMInstall.getInstallLocation() (for example in in JDT/UI) that use the install location as the base directory to construct the path to the Java executables or the Javadoc command. How will this work when the install location is suddendy the location of a .ee file? Or did I misunderstand the request?
Yes martin, that is the request. The API for launching a VM is to use the VMRunner which insulates you from finding the executable yourself. However, this does not allow for running javadoc command.
(Yes, Martin - capital 'M').
A search in the workspace shows that also ANT uses the API to find the tools.jar. The suggested change is a clear API breakage.
Internally, we also use the install location to find an alternate executeable when specified for a VM - i.e. if using java.exe instead of javaw.exe. It appears we do not have proper API for locating executables, and clients are instead depending on the install location.
An alternative would be to create a new "vm install type" to represent JREs derived from ee files. The API for getInstallLocation() would not change. We would need to infer the install location from the ee file, or return null (the spec has always allowed for null, although I'm not sure all clients check for this value).
(In reply to comment #7) > An alternative would be to create a new "vm install type" to represent JREs However, this too has problems since the way the dialog interacts with the IVMInstallType is via set/getInstallLocation()... if it's not allowed to be a file, then this will not work with existing API.
I agree. I did not realize the scope of the impact here. Rescinding my +1 in comment 1. it seems that we would have to add yet another install type or figure out a way of implying a dir from an .ee file. If we can see a clear way of doing this in some reasonable set of cases then we can proceed. Otherwise it feels late in the game for other changes. (sorry, I know I was the one pushing for this. Someday I will be less naive). Adding Andrew for his thoughts on the .ee file/install dir correlation potential.
For now, I will mark this bug as won't fix. I'm going to target the associated feature request for 3.4, where we will have to determine the best path in terms of API.
Note: with the handy new bugzilla flags, you should be able to rescind the +1 by updating the flag value...
very true. I have rescinded my vote As for this being closed, I'm not sure how it will be rediscovered for 3.4.
never mind. I failed to notice bug 181026.
