Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/532.4 (KHTML, like Gecko) Chrome/4.0.244.0 Safari/532.4 Build Identifier: I20090611-1540 We're creating a custom install type by extending org.eclipse.jdt.launching.vmInstallTypes. We need to generate a slightly different command line when launching applications. Creating a special launch configuration would not be correct here because the change really would cross all launch configuration types. We're basing most of it off the 'Standard*' types, just like the Standard11VM... family of classes. The only thing we can't subclass is StandardVM, which has a package-private ctor. Can this be made public? I realize the class is internal. I really do. Pleeeeease? Reproducible: Always
(In reply to comment #0) > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) > AppleWebKit/532.4 (KHTML, like Gecko) Chrome/4.0.244.0 Safari/532.4 > Build Identifier: I20090611-1540 > > We're creating a custom install type by extending > org.eclipse.jdt.launching.vmInstallTypes. We need to generate a slightly > different command line when launching applications. Creating a special launch > configuration would not be correct here because the change really would cross > all launch configuration types. > > We're basing most of it off the 'Standard*' types, just like the > Standard11VM... family of classes. The only thing we can't subclass is > StandardVM, which has a package-private ctor. Can this be made public? > > I realize the class is internal. I really do. Pleeeeease? > > Reproducible: Always In addition, within StandardVM.getJavaVersion(), there is a call to installType.getVMVersion() (installType being a StandardVMType). To all external observation, that method is a protected method, which is confusingly being called from a class which does not implement it. This is preventing me from easily reimplementing the logic as a workaround.
-1 to encourage use of internals. I suggest you reword this bug report to something that can be provided as API, e.g. a VMInstall factory.
Fair point, Dani. I took a shot at it. Do I need a better justification in the meantime?
>Do I need a better justification in the meantime? No I think it's fair. It shouldn't be a big deal to offer the common configs via a factory.
In our particular case, we've got an Open JDK that actually has a slightly different set of command-line options, so just to be sure, a set of standard configs is not quite enough, unless we can subclass or customize the behavior. Maybe a IVMInstallDelegate, etc.? Thanks! Rob
