The colleague of mine just got this from his IntelliJ IDEA 7.0.2:


At least it apologizes…

There is something charming in those small things IDE developers make for us.


My «HashSet.contains(): does your basket contain something?» post got too expected responses: «There is no way to avoid this behavior, why should you expect something else?».

Sure this behavior can not be changed — it’s in nature of any hashed collection. I do not expect anyone to tilt at windmills. What I do expect is, first, ensure I will never stuck with this bug again and, second, prevent others from falling into the same trap. And this is definitely the point I expect the software vendors to help me.
Let’s look one more into the root of the problem: hash code should not be mutable while the entity exists in the collection. Actually, since we can newer be sure it does not, the hash code should never change since the entity was created. Thus, hash code calculation should be independent of object state, i.e. of its mutable fields.

Thus, the following suspicious code patterns should get a special attention in this context (I’ll generally use Java notation, the C# variation is trivial):

  • Mutable hash code: hashCode() accesses fields that are not final, or calls methods that access fields that are not final or call methods that… and so on.
  • Using overridden hashCode(): an instance of class with overriden hashCode() is added into hash-based collection (or one of its interfaces). More general – to any collection instance.
  • Broken contract: hashCode() and equals() do not access the same fields or do not call the same methods (that do not access the same fields… and so on).

What can prevent or warn us about the patterns mentioned?

  • Language level: not really can be taken into account, since providing language-level object identity is almost equal to just forbidding hashCode() override.
  • C# 3.0 anonymous classes make use of similar approach – the hash code of an object is immutable since both equals() and getHashCode() are compiler generated and both fields and properties are read-only.

  • Compiler warning level: may be nice, also implementing recursive method inspection will require new paradigms definition and will add unnecessary complexity. In addition, this require implementing this functionality separate for each platform language.
  • Code inspection: the most desirable option that should act at bytecode level and can be easily integrated into existing IDEs.
  • IntelliJ IDEA 6 inspections list presents a good inspection for mutable hashcode, and something not so powerful for broken contract.

This small and annoying point is just a tiny part of features missing from existing IDEs (expected to provide developer with an ability to concentrate on application business logic development rather than on language or infrastructure implementation details).

One mystery less

March 25, 2007

I was always curious to know what is the engine behind the Miguel’s blog, and now there is an answer from his own.

Lame Blog looks both powerful and simple enough to suit my needs. I think I’ll try it soon.

For the last three years I need to develop in both Java and C# side-by-side, which means almost simultaneous work with different IDEs. Thus the simple and intuitive interface is a must for keeping a productivity pace. And probably the most used and critical feature is a hot key shortcuts for navigating, debugging, refactoring and so on.
Ideally, I’d like to have the same hot key scheme in all my IDEs, so there will be no need to learn and remember how to do the same things twice.
I’m usually working with three commons: VisualStudio 2005, Easy Eclipse and IntelliJ IDEA.
So, what are the offerings?

  • Visual Studio 2005
    “Options -> Keyboard” dialog offers you eight different hot key mapping possibilities that can suite almost anyone used to work with Microsoft tools once. No surprise here: Microsoft, as usual, cares about “their” developers only, but provides a perfect solution.
    Visual Studio 2005 key mappings
  • IntelliJ IDEA 4.5
    “IDE Settings -> Keymap” has four built in possibilities including Mac OS X and Visual Studio schemes. Mac OS X scheme is nice, Eclipse bindings seems to be missing, but Visual Studio is surprising: “wow, they even remember about those migrating from .Net to Java!”. I did not check the later versions, but its probably not worse.
    Intellij IDEA key mappings
  • Easy Eclipse 1.2.1
    “Preferences -> General -> Keys” gives a two possibilities: default and emacs. These guys do not care about anyone using any tool other that their own? Don’t worth a screenshot.
    The most annoying thing is that they do think about this feature: Eclipse has a quick assistance for a hot keys, creating and modifying key bindings is an issue, developers complain about feature weakness and still nothing is done.

The very sad bottom line is: do not expect extra attention to your needs unless you pay…

Comparison overview of bytecode viewer applications Jclasslib Bytecode Viewer 3.0 by ej-technologies and Classfile Inspector 2.0 by Industrial Software Technology.


Recently I faced with a need to inspect a Java bytecode in order to create a tests for bytecode processing application. Googling around showed that the market of the bytecode viewers is narrow and actually there is no large variety of possibilities to choose from.

Viewing Java bytecode generated from the Java source is not too common task for most Java developers, so the choice of the tools in this area is quite narrow. In addition to the bytecode viewers discussed here I’ve found the following additional tools:

Feature comparison table

Jclasslib Bytecode Viewer 3.0 Classfile Inspector 2.0
Pricing Free 10€-99€ per license (depends on license amount), free for students and
License GPL Commercial
Supported platforms Windows, Linux, Unix, Mac OS X 10.1/2 Windows, Linux and others (as plugin)
Installation Platform-specific installation package Jar file. Requires write privileges
Available plugins NetBeans module Eclipse 3.1 (and higher) plugin
Standalone version Yes No
Java versions supported 1.5 1.5
Usability Works smoothly Changing default output directory breaks an ability of viewing *.class file corresponding to java source
Presentation Application windows Text file
Bytecode hierarchy presentation Application window “Outline” Eclipse view
Hierarchy link with bytecode editor Yes Yes
Viewing standalone *.class files No Yes
Exploring *.jar files Yes Yes
Binary data presentation No Yes
Bytecode presentation Yes. Separate presentation for each type (methods, fields, exceptions etc.) Yes. All-in-one text file containing binary data, bytecode instruction presentation and source code
Java source presentation No If available in project
Bytecode decompilation No No
Bytecode modification No Yes
Bytecode validation No No
Links inside bytecode Yes No
Export Method bytecode instructions can be copied to clipboard As any text file

Pros and cons

Jclasslib Bytecide Viewer 3.0

  • Availability as a standalone application
  • Links inside bytecode presentation


  • Limited export ability
  • No binary data presentation
  • No source code presentation

Classfile Inspector 2.0

  • Eclipse integration
  • Mixed binary, instructions and java source presentation
  • Bytecode modification


  • No available as standalone application
  • Limited usability


Classfile Inspector 2.0 is a very powerful bytecode viewer application, with good presentation features, giving an ability of inspecting bytecode created by compiler as a derivative of java source code. This provides a user with an opportunity to understand deeply the way bytecode is generated and the affects of different coding decisions on actual code execution. It looks to be an ultimate helper for anyone teaching or studying Java. The main application disadvantage is its tight binding to Eclipse platform, making it almost useless for those working with any other Java IDE.

Jclasslib Bytecide Viewer 3.0 is a good tool for developer that needs just an inspection view on the jar files containing bytecode created, with no ability to modify it or to follow the influence of source code changes on the bytecode generated. Plugins for IDEs other that NetBeans would be nice, even it always can be used as a standalone application.