Results tagged “Eclipse”

Happy New Year! I planned to have a blog post finished before 2013 ended but this didn't work out. Hopefully this one compensates that a bit.

A little while ago I began preparing another post in my series of Java Tips. Well, this posting is still due but for now I can present you another one where I give a short look on some investigation the preparation of this Java tip required.

It originated in a couple of Sonar warnings on one of our development systems on my job. Specifically the warning about the inefficient way of converting a number to String spiked my interest and I began evaluating the places where these warnings showed up. The warning itself told that there were conversions of numbers to Strings in the form of

String s = new Integer(intval).toString();

which should be better expressed from a performance point of view as

String s = Integer.toString(intval);

Some time during this investigation I became curious if there is really a large effect between the different solutions and wrote a short test case which measured the time of different ways of converting an Integer to a String. Interestingly it did not exactly turn out as clear as I hoped. Initially it seemed that the error claim did not match the reality as my testcase did not show a clear performance advantage of any specific solution. Most ways of converting values to strings were pretty close to each other and the results varied with each execution a bit so I considered this to be mainly a measuring inaccuracy.

// Results with 100000 invocations of each method, timed using System.nanoTime()
new Integer(int).toString()      : 7075890
String.valueOf(int)              : 6570317
Integer.valueOf(int).toString()  : 9597342
Integer.toString(int)            : 11398929

With those combined results I could have been satisfied and discard the Sonar warning as just some hint to write more readable code. But something didn't feel right and after some time I had another look at this. Especially the last measurement looked quite odd. What was the difference between a static call (line 4) and a method call on a new object (line 1) so that the results are about 25% apart. And if so, why is the static call the slower one? Using the Java Decompiler Eclipse plugin I inspected the underlying source. I could have used the the source search engines available elsewhere (e.g. GrepCode) but that was just too cumbersome for a quick investigation and not safe to reflect the actual (byte-)code used. The decompiled source of java.lang.Integer made the observed difference even more mysterious.

...
public String toString()
{
  return toString(this.value);
}
...
public static String toString(int paramInt)
{
  if (paramInt == -2147483648)
    return "-2147483648";
  int i = (paramInt < 0) ? stringSize(-paramInt) + 1 : stringSize(paramInt);
  char[] arrayOfChar = new char[i];
  getChars(paramInt, i, arrayOfChar);
  return new String(arrayOfChar, true);
}
...

Ok, so the call on toString() on a new Integer object is in turn jumping to the static toString(int) method? In that case my previous measurements must have been influenced by something else than just the sourcecode itself. Most probably some effects from JIT compilation by the HotSpot JVM. And therefore the measurements were not usable until I made the effect of JIT compilation neglectable. What's the easy way of making JIT compilation a neglectable factor in measurements? Crank up the number of iterations of the code to measure. The 100k iterations in my first test ran in a mere seconds, maybe not long enough to properly warm up the JVM. But after increasing the iteration count by a factor of 1000 (taking significantly longer to run) following numbers were the result:

// Results with 100000000 invocations of each method, timed using System.nanoTime()
new Integer(int).toString()      : 6044546500
String.valueOf(int)              : 6052663051
Integer.valueOf(int).toString()  : 6287452752
Integer.toString(int)            : 5439002900

Raising the number of iterations even more did not change the relative difference between the numbers much so I think at that stage JVM and other side effects are small enough to not change the execution speed significantly. It also better fits to my expectations of the running costs when roughly brought into correlation of the execution path, logic executed and functions called of each individual conversion variant.

At that point I'm pretty confident that I now better understand the reasons for the initial Sonar warning and that the static method call is roughly 10% faster than calling toString() on newly created objects. And that's even without burdening an additional Integer object to the garbage collection which at a later stage takes some additional time to clean up.

Of course, I'm aware that this is a topic which dives deep into the micro-optimization area. On the other side it can be boiled down pretty easily to using certain methods in favour of other methods, as there is no drawback on safety or functionality and at the core the same static method will be called anyway. Furthermore, ignoring simple performance and memory optimizations may not affect you on small scale like client applications or Java applets but may be pretty relevant on larger (server) systems or even time-critical installations. For a more detailled description why this is relevant on server systems and how it affects throughput and garbage collection times see this excellent list of Java Anti-Patterns.

|

This is my long promised posting about my experiences with Eclipse Mylyn. It took quite some time because I did not stick to it all the time but somehow fell back to my old development-habbits where everything and much more was visible on the screen. Maybe this is caused by the always-changing project situation or changing technologies but I cannot completely blame it to that. Nevertheless, let's focus on my experiences :)

Mylyn works by hiding everything from your visual workspace which is not connected to your current task at hand. This means, you only see the files in the Package Explorer and all other many views which were touched during your current task. This also means that you have to create tasks for your work in the Task List, which is a good idea anyway. The Mylyn-filtering is activated in the moment when you click on the small circle next to such a task in the Task List. If you have worked before on that task, your previous state of the workplace (which is called Context here) gets restored, like the open files, the touched methods and landmarks. If this is a fresh task, you're presented with empty views all around. From here you then can open your initial file to work on either by using the "Open Resource" shortcut or by ALT-clicking into the Package explorer, where the hidden files are displayed then.

From that initial file on you just navigate through the structures and methods with your usual Eclipse navigation (F3, STRG-click, or whatever) and Mylyn takes care to just display and highlight the necessary information for your work. It even cleans up the stuff and removes old and never-again places if you didn't came back to them for a longer time. The same thing applies to all content-assists like the method-overview or all of the Find-shortcuts where the list gets two-parted with your context-relevant results at the top and only the remaining hits after a separator.

You can also mark certain methods or files as "Landmarks" which are then displayed in bold text in your Outline or Package Explorer. This is especially handy if you're hunting a bug and found important places you want to remember or where you nailed down the cause but will fix it at a later time.

I also tried to connect my Mylyn Task List with a local installation of Bugzilla to better manage my tasks and make them available even outside of my own workspace. This worked quite good. It's also possible to attach the Context to each task if you're working with an external task repository. This would allow other people on the same repository to open the Context in the same state as it was when you last saved it to the task repo. Easy moving tasks from one person to another :) But we didn't come around to test this, as I've been the only one to work with Mylyn longer than just for a short tryout.

All in all I can say that if you get used to the way how Mylyn hides everything unnecessary from your display and how it presents the important information, the speed of development really goes up and the amount of distraction minimizes. But to get to that point you have to really work through the initial get-used phase which can be somewhat confusing and make you switch back to the previous development-mode where everything is displayed. I also fell into this a few times. But if you stick to it, you'll soon get the benefit of being able to focus!

If you also want to try it out or are just curious how it feels to work with it, take a few minutes and watch the Eclipse Mylyn 3.0 webcast video and read through the Mylyn 2.0 Tutorial (still applies 100% even if it's been written for 2.0) how to get started, you won't regret it!

|

Last time I've been posting about how you can increase your java development speed by knowing and using common and handy keyboard shortcuts. This time I'll be showing you some plugins which I have used over the time. For most of them I can say that they not so much speed up development but instead raise the quality of your sourcecode by giving you hints or adding certain aspects to testing.

So let's dive in.

Subclipse and Subversive are with high probability the most-installed plugins for distributed development and source code versioning. As Eclipse still does not provide builtin functionality for this (because of some licensing issue), these plugins add the required connectors so that it becomes possible to synchronize your source with a SVN server. Both plugins provide everything needed for most of the SVN tasks and differ just in edge cases or the handling and UI details. I'm personally using Subversive for years now because it has a Checkout-Wizard with more functionality than Subclipse offers but that plugin also has evolved since I checked it the last time. I should give it a try again in the near future.

The JD-Eclipse plugin is a decomplier addon for Eclipse which helps you out if you happen to stumble into Java bytecode eg. during debugging or when you follow references into external libraries. It reconstructs the Java source from the compiled code, so what you get is not the real sourcecode but something which resembles exactly the same function. Nevertheless it's often interesting how the code behind the APIs works you're using. Or, if you're depending on other projects which are currently just closed in your workspace.

Findbugs is a static source-code-analysis tool which checks your sourcecode for common mistakes optimization potential. It covers a very wide range of different bug types and each found bug or issue in your sourcecode has a small description added. Of course, since it's a statical analysis this tool is unable to analyze the whole logic in your sourcecode and therefore may also generate false positives, so be sure to not blindly follow each suggestion. But it's usefulness in general is undeniable.

Also a static analysis is done by Checkstyle but this one focusses less on programming errors but more on the layout of the code and the correctness of the documentation. For example if your javadoc for a method is missing a new parameter which you just added, Checkstyle would highlight this mismatch for you. It has an extensive ruleset so don't be surprised if it makes annotations all over your code if you check it for the first time.

EclEmma and Coverlipse are two plugins which deal with identifying the runtime coverage of your code. They add measuring instruments which allow you to determine which parts of your code are reached by eg. unittests and which parts of your code are still untested and need additional attention. EclEmma is the simpler one of the two but also is faster to get started with. Coverlipse on the other side needs a bit more work to get started but allows deeper inspection and offers a wider range of statistics and visualizations of the covered and uncovered code.

Another tool to aid with testing is Infinitest. It analyzes your JUnit tests and runs them silently in the background after each change in your sourcecode. It adds some intelligence so that only those tests are run which could be influenced by your changes. Furthermore errors in the tests are directly displayed as source-errors in your sourcecode. Of couse, this is only useful if your testcases can be executed fast and do not need an extended time to execute. The plugin has moved from the free Google-Code project to a commercial website but as far as I can see, the plugin itself is for now still available without cost.

If you want to quickly set up a shared task repository for your small team without having to set up a full blown Bugzilla, maybe even with a touch of Scrum, Scrum Vision may be the tool for you. It connects the task management of Eclipse (Mylyn) with a Google spreadsheet which also can be shared with other instances of Eclipse for other developers. The IDE aligns with the Scrum methodology to support agile development. This alignment also propagates in the spreadsheet where you can display reports and have a virtual taskboard and also a Burndown Graph.

If you'd like to close editor tabs the same way as you do in Firefox, by middle-clicking the tab, the Middle Click Closes Tab plugin (although last updated for Eclipse 3.3, it still works with Galileo) enhances your Eclipse with this feature.

As for Mylyn, which is already completely integrated in Eclpse: Since my last post according Mylyn I collected some additional experience with Mylyn. I also connected it to a local instance of Bugzilla to play a bit around with its integration and how it deals with sharing files and context. But I also think that I should use it more again, as I've become a bit lazy with it and fallen back to the previous everything-on-the-screen overloaded development. The promised blog post which hasn't been posted until now is still on my list for the future, when I know even more about Mylyn. But I already can suggest Mylyn as a tool to leverage the development effectivity by helping the developer to focus on the actual task at hand. If you're curious, have a look at the excellent Mylyn 3.0 webcast to get started.

That's it for now. I hope, there is also something useful in this post which is helpful for your Java development with Eclipse.

|

Since I've started developing Java in Eclipse I have realized that this is in no way different than with most other IDEs: the speed of development highly depends on the knowledge and intuitive usage of keyboard shortcuts.

Occassionally I'm asked to slow down a bit so that one can follow my actions or to tell which shortcut I've just used. For this reason I'm making this small list of those shortcuts which I'm using pretty much all the time.

I've tested these shortcuts specifically on Eclipse Galileo (3.5.1) and on Windows but most of them are also already present on earlier versions of Eclipse. As for other platforms I don't really know if all of them (or even any one of it) are available (or at the same combination). Furthermore many of them should also be present when developing different programming languages than Java but I cannot confirm that. You just have to find out yourself. Just in case you do, please let me know in the comments :)

So without further ado:

Shortcut Function Description
CTRL+SHIFT+ROpen Resourcebrings up a dialog where you can quickly locate any file or resource in your workspace. Wildcards are supported in the search.
CTRL+SHIFT+OOrganize Importscleans up the imports-block at the beginning of the file. Adds missing imports (if neccessary) and removes unused ones.
CTRL+SHIFT+FFormatapplies proper formatting to the source code according to the style-settings in the *Java->Code Style->Formatter* preferences.
ALT+UP/DOWNShiftmoves the current line or selection up or down one line. Very useful for fast relocation of code, much faster than cut/paste if just moving a few lines.
CTRL+ALT+UP/DOWNDuplicateduplicates the current line or selection above or below the current line/selection. Allows the fast population of cases in switch/case statements if they differ just marginally or similar situations like variable-initializer blocks. Beware, that this shortcut is often also overridden by some Intel display drivers. If this one does not work for you, try to turn off or change the hotkey assignment in your display driver helper application.
CTRL+OQuick Outlnebrings up a small dialog which allows to search and navigate the outline of the current file. Just start typing to narrow down the results. Supports wildcards. Pressing CTRL-O again toggles the display of inherited methods.
CTRL+PGUP/PGDOWNSwitch Tabchanges to the next/previous editor-tab.
ALT+SHIFT+LExtract Local VariableCreates a local variable from the currently selected expression. Types are automatically added. Try it on the code 'new HashMap();' to understand how this can speed up your development. Works on variables, static strings, methods with return values, etc.
ALT+SHIFT+IInline Variableopposite of local variable extractions. Replaces all occurences of the currently selected variable with its assigned value. Only works if the value of the variable is set exactly once.
CTRL+ALT+HCall Hirarchyshows all calls/usages of the currently highligted variable/interface/class/method.
F3Open DeclarationJumps to the declaration of the currently highlighted variable/interface/class/method. Similar to holding down CTRL and clicking with the mouse on a variable/interface/class/method.
CTRL+SHIFT+LShow Key AssistDisplays a popup which displays currently assigned keyboard shortcuts. Very useful if you are looking for further shortcuts quickly. A shortcut for shortcuts ;)

There are many more shortcuts available, including the marking and navigation shortcuts which you should know from Microsoft Word, but the above ones are the ones which became ingrained in me and are now speeding up my Java development enormously. Try to get used to them and use them whenever you can and you'll realize that there will be fewer and shorter interruptions to your stream of thought and it also aids your concentration.

If you want to go a tad further and let Eclipse tell you about possible shortcuts (or even force you to use one by cancelling all mouse-events which have a shortcut) you can install the MouseFeed Eclipse Plugin which does exactly this by displaying a small shortcut reminder each time you issue a shortcutted command with the mouse. Although it's a plugin for Eclipse 3.3, it still works with Galileo.

| | Comments (1)

1

Archives