Stefan Dollase Stefan Dollase - 26 days ago 13
Java Question

Moving static code analysis from a separate process to an Eclipse plug-in

I am currently working on an Eclipse plug-in for a static code analyzer. The analyzer is written in Java. Until now, the Eclipse plug-in used an own launch configuration type as well as a subclass of

JavaLaunchDelegate
to execute the code analyzer in a separate process. The Eclipse plug-in and the code analyzer communicated via stdin and stdout of the new process. It was quite ugly :-P

Now, we aim to clean this up. First, we converted the code analyzer to be not only a jar file, but also an Eclipse plug-in. Second, we replaced the stdio based communication by a proper Java interface: The code analyzer offers an API to the Eclipse plug-in. This all works fine.

However, the Eclipse plug-in still uses its own launch configuration type with its subclass of
JavaLaunchDelegate
to run the analyses. This means, since the code analyzer itself is now an Eclipse plug-in, the analysis is done in the same process. However, the Eclipse plug-in still launches the extra process with the code analyzer without using it.

Question



What do we still need from the old setup?

I am quite sure, we can convert the
JavaLaunchDelegate
to a simple
LaunchConfigurationDelegate
. This should prevent the Eclipse plug-in from launching the useless process.

Next, in the
plugin.xml
, we declare the own launch configuration type like so:

<extension
point="org.eclipse.debug.core.launchConfigurationTypes">
<launchConfigurationType
delegate="com.example.LaunchDelegate"
id="com.example.launch.config"
modes="run,debug"
name="Launch"
sourceLocatorId="org.eclipse.jdt.launching.sourceLocator.JavaSourceLookupDirector"
sourcePathComputerId="org.eclipse.jdt.launching.sourceLookup.javaSourcePathComputer">
</launchConfigurationType>
</extension>


Here, I am not sure whether we can remove the
sourceLocatorId
and
sourcePathComputerId
attributes: The launch configuration still launches Java code, but it is no longer launched in a separate process. Do these attributes make sense when they are used with a launch delegate that is not a
JavaLaunchDelegate
?

Finally, I don't know whether it is a good idea to still use a launch configuration at all. This is because we don't really launch an extra process, but an operation that is executed in the Eclipse process. Is it appropriate to use a launch configuration for this use case? Also, we currently use a subclass of the
AbstractLaunchConfigurationTabGroup
to configure the parameters of the analysis. Is there an alternative to the own launch configuration type that allows us to launch an operation in the Eclipse process and to provide parameters via a GUI for this operation?

Question Summary




  1. Can we replace the
    JavaLaunchDelegate
    with a simple
    LaunchConfigurationDelegate
    ?

  2. Can we remove the
    sourceLocatorId
    and
    sourcePathComputerId
    attributes from the own launch configuration type declaration?

  3. Is it appropriate to use a launch configuration to execute a static code analysis that runs in the Eclipse process?

  4. If it is not, is there an alternative to the own launch configuration type that allows us to launch an operation in the Eclipse process and to provide parameters via a GUI for this operation?


Answer

We now use a simple LaunchConfigurationDelegate and we removed the sourceLocatorId and sourcePathComputerId attributes from the own launch configuration type declaration. This does indeed prevent the unnecessary process. Also, we did not notice any issues with the debugging. Thus, I consider question 1 and 2 as solved. Regarding question 3 and 4: The simple launch configuration now works fine for us, so we stick with it.

Comments