ryank

Jan 212013
 

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:

  1. Copies existing sample java files to eclipse into a NEW project in a NEW workspace
  2. Initiates Eclipse
  3. Chooses the new workspace location
  4. 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:

  • http://stackoverflow.com/questions/11302297/automate-import-of-java-android-projects-into-eclipse-workspace-through-comman

 

 Posted by at 5:04 PM
Oct 232012
 

90% of the time invested into the development of computer software pertains to testing. A portion of a source code is written, tested, debugged, fixed, tested again, and rewritten in portions. At least that’s my procedure: Write, test, fix a couple lines, test again, and rewrite, and test again… it’s exhausting. And finally, when you think you have it right, the build is released to your clients and users, to find out 10 days later that they have found a few more bugs, sent to you via emails and bug reports.

Testing comes in a gamut of methods: debuggers, unit tests, logs and exceptions, user trials, etc… All of which are used procedurally after compile time. But what if there was one more dimension of testing? …One that occurred before compile time. After all, compiling and building so often can be time consuming, especially if we are talking in terms of tens of thousands of lines of code. Another method exists. That dimension is called Static Code Analysis. It’s something that I have researched and trialed in the recent weeks, and it works prior to compile time.

Static code analysis is a dimension of code testing occurring before compile time. It analyzes your code line by line. It will find areas where errors are bound to occur or have a good probability of occurring. Many static code analysis tools will also find duplicate code (which can cause errors if the original source of the duplicate contains an error itself or is changed later, after being duplicated). Many also offer optimizations. You can also adjust your settings to allow the analyzer to search for common code styling issues and ensure that a code complies with common style standards or company specific style standards (although I have all the style checking settings deactivated as they are not a top priority and cause many needless suggestions).

Our code is written in C# with .Net. I tried a dozen different static code analyzer tools. Many of these tools were obsolete and didn’t offer any productivity to testing. Others offered so many suggestions in its findings through which I spent too much time sifting and examining that I added no efficiency and productivity to the testing and debugging process. Others were so expensive (into the tens of thousands of dollars) for a license that it was hard to justify the cost. One stood out, however. ReSharper by JetBrains (the creators IntelliJ IDEA) is exactly what I was looking for.

ReSharper is a plug in to Visual Studio. ReSharper can analyze an entire solution or project with tens of thousands of lines of code in about 60 seconds. It generates a report with a gamut of issues, including styling practices, refactoring, code quality issues, redundancies, internationalizing assistance, and offers many suggestions with quick fixes, fixing a line with a click of a button. ReSharper offers over 900 code inspections. Impressive but maybe a bit daunting? Go to the ReSharper settings and deactivate the inspections that you do not want ReSharper to perform. In the settings, I deactivated the hundreds of style suggestions ReSharper offers since styling is not a top priority for me, bringing what truly counts to me: potential errors and optimization suggestions. ReSharper also has the capability to examine the following formats: C#, VB.NET, XAML, ASP.NET, ASP.NET MVC, JavaScript, CSS, HTML, and XML.

Here are a few examples…Many areas in the code, Lists are used with the understanding that they must not be null. However, it was innocently forgotten to assert the truth that those lists are in fact not empty. ReSharper reminded me that these Lists had the potential to be null, which would cause a runtime error, and with the click of a button, added an assert statement to affirm that a list was in fact non-null. Another common occurrence in the code was the Boolean comparison of two floating point numbers. Due to the way floating point primitives are implemented, if a number or its decimal is not a power of 2, it will lose its precision due to rounding. Therefore, comparing a floating point number can generate the incorrect result because of that minor rounding detail. ReSharper found these areas and offered suggestions to fix the code. Another, ReSharper found conditionals that always returned true or false, causing unreachable code in areas. This may or may not be intentional on the programmer’s part, but it is still beneficial that ReSharper reminds the programmer of this, in the case that it is unintentional and causes an unwanted error. All this, along with other errors were found before Compile time and Run time, saving me the trouble of trying to debug these aspects with various unit tests and having our clients run into any potential issues.

ReSharper is definitely worth looking at and worth the investment. Their website is: http://www.jetbrains.com/resharper/

Still not convinced?… do some research of your own as well. The following Wikipedia link has a long list of other static code analysis tools: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Happy Coding,

-Your fellow tech friend

 

 

 Posted by at 11:41 AM