The battle persists – Eclipse vs. IntelliJ. Every developer has his or her own opinion. And there lies the issue. Some of our clients are developers themselves and have their own opinions as to whether they should use Eclipse or IntelliJ as their go-to IDE.
We offer a light-weight tutorial software solution that opens sample Java projects to our clients, and therefore the need arises to port those samples to both Eclipse and IntelliJ. I was recently put to the task to build a process that could open these Java sample projects in the user-preferred IDE at the click of a single button (I.E. A user specifies whether he or she favors ‘Eclipse’ or ‘IntelliJ’ or ‘Other’ at start up, and when he or she clicks a button to view a Java Sample, the sample project will be opened in that preferred IDE automatically). Automated importing, switching the workspace, and seamless compatibility on the user’s end…That was the goal.
IntelliJ was simple. Each sample simply required a premade .ipr file (IntelliJ IDEA Project File). The code I build could then call a process to open the .ipr file with IntelliJ saved in the registry… and Bam! IntelliJ opened with the Java sample project. No more than 10 lines of C# code.
Eclipse… that’s a different story. It’s quite a process to initiate Eclipse. Eclipse doesn’t really have a project file type (beyond the .classpath and .project files) that can just be called by a process and automatically open Eclipse from registry information like IntelliJ. To accomplish opening Eclipse with the Java sample files, I had to write code that automatically:
- Copies existing sample java files to eclipse into a NEW project in a NEW workspace
- Initiates Eclipse
- Chooses the new workspace location
- Views project
Luckly, Eclipse can be initiated in a command line process with various argument tags to specifying the workspace. Therefore, I can programmatically open Eclipse with a workspace by creating a new process that executes the following:
\Path\To\EclipseFolder\eclipse –nosplash –data \Path\To\New\WorkSpace\
- -nosplash opens eclipse without the initial splash screen
- -data specifies the path to the new workspace to open
However, the now-opened Eclipse will not show any projects or files. To do that, one must import a project into that workspace. If one is using CDT (Like Eclipse but for C/C++ coding), then he or she has the great fortune of having the “–import” argument tag which will take an existing project from any specified location and automatically make a meta data file that specifies that project to import. Unfortunately, standard Eclipse does not carry this support. SOOO… I had to build an “Eclipse Plug In” that could allow for this import functionality. The plug-in would then have to be saved into the ‘dropins’ subfolder of the folder where the user’s Eclipse distribution is saved. That being said, the following could be executed and do exactly what I need:
\Path\To\EclipseFolder\eclipse –nosplash –data \Path\To\New\WorkSpace\ -import \Path\To\Existing\Project
Bueno… Everything is good right? NO. To be more in depth, the tutorial software process that does all this is written in C#. That C# code calls a process to execute the above command. However, unfortunately, the plug-in script that I wrote to allow for the import functionality must be written in Java to work with Eclipse (as Eclipse is also written in Java and runs completely on a JVM). So, essentially 3 things are happening right now. C# code is initially running and calling a new process, executing a hidden Command Line which calls the above command, which in effect executes a JVM to be able to run my plug-in script for the import. This causes major inefficiency, and on my machine causes about 15 to 20 seconds in lag time. Also, not to mention, the above command must know the destination of eclipse distribution on the user’s machine, which is arbitrary with no insight as to where it is since Eclipse information is not saved into a registry on Windows. So my C# code must prompt the user to locate his or her Eclipse distribution for me. From there, the C# code must copy the importer plug-in code into the ‘\dropins’ subfolder of that Eclipse distribution. From there, the C# code calls a process, which executes the appropriate command above, initializing the JVM to execute the imports, and then calls to open Eclipse with a specific workspace. Once everything is set and done, and Eclipse is opened, the project files are all magically there in the correct workspace, as desired. So the goal was achieved. But at what cost!? This solution is clunky, inefficient and inelegant and does not allude to the seamless, easy-to-use tutorial software we are aiming to distribute. And if the auto-generated meta file isn’t perfect, well… the project build won’t work, meaning the files are there, but they cannot easily be compiled.
Long story short, we cannot distribute a product that is glitchy and clunky. So, although with great effort to cater to the developers using Eclipse, we had to ultimately bag the Eclipse inclusion and only support automated IntelliJ project openers. Those who do not use IntelliJ can still view the Java source codes, but they will rather be opened in a folder. However, the nicety behind opening an IDE to view the Java samples sadly does not exist if one is not using IntelliJ. If Eclipse could get its act together and create a specific project file like IntelliJ’s “.ipr” that can be saved in a registry along with an Eclipse distribution that is installed and saved in a registry, this could have easily been avoided.
Specifically, the following link is the documentation to Eclipse Command Line Options:
Also, here is a link to the location where I found information about building an importer Eclipse Plug In if you are interested: