What is the difference between getJDK and getModuleJDK
1)
com.intellij.execution.configurations has these two methods
getJDK
and
getModuleJDK
both return a ProjectJDK. I guess that one returns the module JDK and the other returns the JDK , but as a practical matter, I don't really know what that means. When and why would they differ? If I am writing a plugin under what circumstances would I want one and not the other?
My goal is to locate the JDK that, I guess, is running the instance of intellij in which my plugin is being invoked by the user? Is there any reason normally to want another ? I do not know the driving use cases behind this API.
Oh and also there exists com.intellij.openapi.projectRoots.getInternalJDK ... just a little confused. At any rate, I am not able to find an object that wants to give me a ProjectJDK. This fails :
JavaParameters javaParameters = new JavaParameters();
or at least the ProjectJDK it returns is null. I looked for returned by in the OpenAPI... a number of abstract classes return it. ...
2)
Also, I need to call out (literally, express as a String in the normal running of my plugin) a name of a .class file which will be located in my plug-in directory. Is there a shortcut utility method that gives me the name of that directory from whatever current directory I happen to find myself in when the user executes my plugin?
Message was edited by:
softwarevisualization
Please sign in to leave a comment.
What class in com.intellij.execution.configurations? JavaParameters? Please be more precise.
The source for this class (JavaParameters) is available. You'll see that getJDK() returns the value set by the configureByModule|Project() methods and getModuleJDK() is a utility used by configureByModule() to get the module's effective JDK.
com.intellij.openapi.projectRoots.ProjectJdkTable#getInternalJdk may be what you're looking for. Although the normal process is to work with the JDK that's configured for the project/module and not the one that runs IDEA.
See com.intellij.openapi.application.PathManager#getPluginsPath
This might work as well, but uses non-OpenAPI stuff:
Sascha
let's talk about jdks and jres.
Well, there's the one that intellij-the-editor by jetbrains runs on when it starts up with, maybe, no projects.
Then there's the one that the end user specifies for the Project she is writing- use JDK1.5 for this project (say).
Now here come the plug-ins. What JDK are they using?
Well for one, since the plugin was once a project which needed it's JDK specified, we know it's compiled and dependent against some jdk version. So when it's run, it needs to find a compatible library version. But where does that library version come form? The plugin doesn't "ship" with it's own jdk version- surely it uses the same one as intellij-the-editor.
So maybe the following is true and useful-
if the effect of running the plugin is to inject java statements into the source code of the plugin user, statements which will later ship from the user to the consumer,. then the plugin needs to know the jdk version the plugin user intends to ship their product with.
if the effect of the plugin is just to run some process but write no code into the plugin user's code, then use intellij's jdk.
So if you invoke getJDK from a JavaParameter object, you'll get an object. whose methods getBinPath() getHomeDirectory() getRtLibraryPath() getToolsPath() etc refer to the JDK the user specified for her project / module
But if you want the runtime jdk of intellij you want com.intellij.openapi.projectRoots.ProjectJdkTable#getInternalJdk.
I am not sure if that' s right, but it seems reasonable.
So in general, if you want to understand something, and it's not documented, what can you do?
You can look at the source and see how it's used.
You can guess by the name of the method/class etc.
You can invoke the method (if you can assemble / create the prerequisite objects) and poke at it using sout etc.
You can load up the OS plugins and search those for usages and repeat the above.
The problem is, more often than not the class is not used in any question resolving way, or not used at all in the OS plug-ins, and what's more, is not actually implemented in the OpenAPI, (as we might expect) which defeats most of the above steps.
For example, at least on my set up, ModuleRootManager, one of the classes in this ProjectJDK question, was reported to have NO non-abstract implementation and anyways merely inherited the getJDK method from an interface ModuleRootModel, which in turn reported ModuleRootManager as the only (abstract) implementor.
So you can see it being used as you described, but not in ways that really clear up too much unless you already know about it.
The only reason I bring this up is not to complain but to see if other people have novel ideas for rooting out this kind of information...
Message was edited by:
softwarevisualization