Technoblog by Boris Kirzner

301 Moved Permanently

Boris Kirzner — Sat, 29 Mar 2008 14:35:47 +0000

This blog has permanently moved to http://boris.kirzner.info/blog/

The rule of thumb

Boris Kirzner — Thu, 03 Jan 2008 09:12:30 +0000

If you may configure something using Spring — never ever try to configure the same thing with Hibernate.

Sorry, Gavin.

Is the modern software getting more and more humanlike?

Boris Kirzner — Thu, 20 Dec 2007 17:10:47 +0000

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

At least it apologizes…

Good old IE bug?

Boris Kirzner — Mon, 12 Nov 2007 12:54:01 +0000

May someone explain me why the following HTML code is causing IE6 SP2 crash?

<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<table>
    <tr>
        <td>
            <table style="table-layout:fixed">
                <col width="20"/>
            </table>
        </td>
    </tr>
</table>
</body>
</html>

Bonus: CodeColorizer

Playing around with IntelliJ IDEA 7

Boris Kirzner — Tue, 30 Oct 2007 08:11:06 +0000

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

Mainsoft makes one more step forward to developing Grasshopper community

Boris Kirzner — Wed, 11 Jul 2007 12:52:08 +0000

This week Mainsoft introduced a new source of information for all Grasshopper users: «The Grasshoppers» blog.
Although currently there is only one person actually blogging there, this is a promising step forward to developing a rich community of both Grasshopper users and developers.

By the way, it worth to take a look at full Grasshopper bloggers list.

Mono and CafePress

Boris Kirzner — Tue, 26 Jun 2007 06:36:25 +0000

Since CafePress is still lacking any kind of Mono project stuff, I decided to make one of my own.

There is nothing better than starting you morning with a good cup of Mono…

Source code inspection framework wanted

Boris Kirzner — Mon, 11 Jun 2007 08:07:27 +0000

Another example of problem similar to hashCode() mutability is an option for broken «consistent with equals» contract imposed by implementation of java.util.TreeSet while implementing java.util.Comparator.

Actually, both of these cases (as well as a numerous others) are just an evidence of much wider problem – the requirement to follow some kind of contract various infrastructure implementations rely on and lack of ability to validate/impose such a constraints using existing IDEs and tools. The basic of this is the fact no IDE vendor can track an implementations of an infrastructure libraries existing (the best support feasible to achieve is Microsoft-style solution: an inspection for .Net framework libraries embedded into Visual Studio) and thus creating inspections “by reaction” will always loose the battle.

The best way to avoid the gap between software component and the inspections is to eliminate the “broken phone” between the software developer, the documentation developer and the inspections developer. This presents an «inspection by creator» paradigm – inspections are developed in parallel with a software component (and in ideal case by the the same software developer), embedded within the component, and shipped with it.

Summarizing the basic requirements for such a framework:

Development simplicity: the inspection language should provide a way to create an inspections in declarative manner, rather than by reflection-style coding.
Lexical compliance: the inspections declaration language should be close enough to the syntax of programming language constructs inspections apply to (thus, there should coexist inspections framework implementations of the common functionality for the different platforms like Java and .Net and different per programming language extensions on the same platform like C# and VB.Net).
Multiple inspection sources: there should be and option for predefined inspections (shipped with the framework), vendor inspections (developed and shipped with particular software component) and ad-hoc custom inspections (in-house development of software component users).
Binding: there should be a way to associate the inspections with the related code structures (classes, methods, fields and properties) and ideally — keep and maintain them within the code.
Universality: inspections should be applied in «to subject» and «to object» manners (i.e. relate to the code structure associated with the inspection or to the code caller).

Upon meeting the two first requirements the last three can be easily accomplished by using existing standard mechanisms like annotations and attributes.

A new security blog around

Boris Kirzner — Tue, 05 Jun 2007 08:32:35 +0000

Imperva CTO, Amichai Shulman has launched his own security-oriented blog.

He moistly writes about enterprise security «metas», providing a lot of valuable background information resources. A must-read for any enterprise-level developer.

Back to hashCode() mutability

Boris Kirzner — Tue, 29 May 2007 12:55:44 +0000

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).

Bad day for blogging?

Boris Kirzner — Wed, 16 May 2007 08:17:58 +0000

Both Monologue and ASP.Net Weblogs seem to be down for some time.

C# 3.0 Automatic Properties

Boris Kirzner — Wed, 16 May 2007 07:18:22 +0000

Yesterday I read two excellent posts about C# 3.0 automatic properties feature: ScottGu’s «New C# “Orcas” Language Features: Automatic Properties, Object Initializers, and Collection Initializers» and Bart De Smet’s «C# 3.0 Automatic Properties explained».

It was a pleasure to see that my old «A programming language pattern idea» hit straight to the point.

By the way, this “Orcas” feature is still missing the “container” concept, enabling an access to the auto-generated field from the constructor. Another missing point is a read-only automatic properties.

One mystery less

Boris Kirzner — Sun, 25 Mar 2007 07:18:33 +0000

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.

Mainsoft out, Imperva in.

Boris Kirzner — Wed, 21 Feb 2007 10:05:16 +0000

I’m changing my employee, leaving Mainsoft and moving to Imperva.

I’ve already get a farewell present better I could ever imagine: support for Visual Basic in Mono was announced. Thanks to Rolf, Miguel, Lluis and others who made this happen.

Working with Mono team was one of the best professional experience occasions I ever had. It may be difficult, but now I will have to get used to my new role as Mono user-only.

Still tuned with Monologue and DevZone.

My private IDE war : small things make a big difference.

Boris Kirzner — Mon, 11 Dec 2006 13:34:18 +0000

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.
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.
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…

Why being paranoid is a must for keeping a good service?

Boris Kirzner — Fri, 20 Oct 2006 18:47:45 +0000

Technorati Profile

HashSet.contains(): does your busket contain something?

Boris Kirzner — Sun, 01 Oct 2006 21:35:47 +0000

When you put some good into your supermarket basket, you really suppose it will stay there, don’t you? Well, we’re living inside materialistic world. All of us, except Java programmers.

Consider the following Entity class:


       public static class Entity { 
       private String _name; 
       private int _count; 
 
        public Entity(String name, int count) { 
            _name = name; 
            _count = count; 
        } 
 
        public void setName(String name) { 
            _name = name; 
        } 
 
        public boolean equals(Object o) { 
            if (this == o) return true; 
            if (o == null || getClass() != o.getClass()) return false; 
 
            final Entity entity = (Entity) o; 
 
            if (_count != entity._count) return false; 
            if (_name != null ? !_name.equals(entity._name) : entity._name != null) return false; 
 
            return true; 
        } 
 
        public int hashCode() { 
            int result; 
            result = (_name != null ? _name.hashCode() : 0); 
            result = 29 * result + _count; 
            return result; 
        } 
    }

Let’s store our entity into various Java collections instances, both implementing Set interface:


    
        Set hashSet = new HashSet(); 
        Set arraySet = new CopyOnWriteArraySet(); 
         
        Entity e = new Entity("OldName", 5); 
 
        hashSet.add(e); 
        arraySet.add(e);

Now, let’s see whenever the previously stored entity is still inside the collections:



        System.out.println(arraySet.contains(e));  // returns true 
        System.out.println(hashSet.contains(e));   // returns true

Now, a simple mutation, changing an entity name:



        e.setName("NewName");

And, voila — now the entity is still in ArraySet, but not in TreeSet:



        System.out.println(arraySet.contains(e)); // returns true 
        System.out.println(hashSet.contains(e));  // returns false

This looks like a quite stupid bug from the first time, but googling aroung brings an answer: TreeSet implementation uses hashCode() and not equals() for storing and retrieving entities, thus TreeSet requires hashCode() of contained entity to be immutable!

Presonally I think it’s too smart to be good, but, let’s say “the big brother knows beter”. The really annoying thing is that the request for proper documentation of this feature was initially issued for Java 1.3.1 at 16 May, 2001 and nothing was done since that.

Shame on you, Sun Microsystems…

Visual Studio developers, welcome to Mac OSX :)

Boris Kirzner — Thu, 28 Sep 2006 10:14:03 +0000

Yes, we did it.
The fruit of mine and Rafi’s work: .Net IBuySpy application running on Tomcat on Mac OSX (using Grasshopper 1.8):

N.B. This post was originally created 100% totally using Mac OSX Safari.

Bytecode viewer tools: Jclasslib vs Classfile Inspector.

Boris Kirzner — Thu, 24 Aug 2006 12:59:52 +0000

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

Introduction

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:

ASM Bytecode Outline plugin for Eclipse – provides an ability of viewing bytecode instructions for current method and/or ASMfied view of the method code.
JavaP plugin for Intellij IDEA – last updated in June 2003, seems to be dead project.
JProfiler by ej-technologies – Java profiling application claims to have a bytecode presentation feature when integrated with IDE like Intellij IDEA (probably it uses Jclasslib as underlying library).

Feature comparison table

	Jclasslib Bytecode Viewer 3.0	Classfile Inspector 2.0
General
Pricing	Free	10€-99€ per license (depends on license amount), free for students and teachers
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
Features
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
Pros:

Availability as a standalone application
Links inside bytecode presentation

Cons:

Limited export ability
No binary data presentation
No source code presentation

Classfile Inspector 2.0
Pros:

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

Cons:

No available as standalone application
Limited usability

Summary

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.

«We bee!» aka Visual Basic reloaded

Boris Kirzner — Sun, 20 Aug 2006 09:58:00 +0000

Last time we (me, Rafi and others) were working on new Microsoft.VisualBasic.dll implementation, fully rewriting it in Visual Basic and extending the library with .NET 2.0 features. New implementation brings a both quality and coverage breakthrough, passing 3200 tests more that the old one.

Thanks to Rolf it now can be compiled with vbnc, making it true «VB implemented in VB».

Its now a community time to pick up the «Coding Flame» and continue with the further implementation.

A new Microsoft.VisualBasic.dll implementation is available in Mono SVN repository at svn://mono.myrealbox.com/source/trunk/mono-basic