Konstantin I. Boudnik's Blog

March 2006 Archives

New Java VM blog is coming...

Again a message mostly for those, who is speaking or at least reading Russian. Our folks from Saint-Petersburg I was writing about this great city before SQE team are starting their own blog, designated for the Russia-speaking development crowd.

The blog, I believe, will be a real first hand's value-add for existing Java VM resources, about modern VM techniques, tools, security features, co-existence with .NET, etc.

There isn't much right now, but the folks will carry on fast, I think.

You can find this new information resource at at the official Sun blogging site

So, if you have colleagues or friends, who are suffering without such information, written in Russian - please pass by my message or simply the URL above. Let's wish them good luck and God speed!

--
Thanks
Cos

Java APIs comparison

We recently thought about an interesting approach of finding a difference between APIs (public methods) of two versions of a Java software. I was doing it for JDK1.5 (Tiger) and JDK1.6 (Mustang b76).

Sometime you might want to take a quick look and find out what exactly has been changed in your (or somebody's else code) between two versions. Why? Well, if you want to focus your test development on the new API only it might be a very sound idea. I'd spoke about some of other methods to help you to achieve better software quality
Well, there are some methods to do so. E.g. you can use "Since" tags from a Javadoc Well, good if you have any...

Or you can store your product API's snapshot like RefactorIt does. Boy, what if you didn't create this snapshot in a first place and now you badly need one? "Sorry partner - no can do for ya..."

Anyways, the idea was on the surface as usual:
In one way or another build a list of all public (protected/private/static/etc.) methods in your software. You can use grep or javap along with grep for these purposes. Don't forget to do this for both versions of your application - it's about the difference, right? :-)

Now, you have these API lists, you just need to compare them. And again it's up to you: you can use Unix diff command, Emacs ediff, or vimdiff. I'd wrote that self-explanatory Perl script (feel free to modify it, criticize it, or merely throw it away). Fix &open_file()'s loop if your API lists weren't created in the form of "filename:method signature" per line...

#!/usr/bin/perl

if ($#ARGV != 1) {
    print "Please supply two lists of APIs you want to compare\n";
    exit 1;
}

my %diff = ();
my $left = &open_file ($ARGV[0]);  #Presumably, the earlier version
my $right = &open_file ($ARGV[1]); #Presumably, the latest version

foreach $file (keys %$right) {
    if (!exists $left->{$file}) {
	$diff{$file} =  \@{ $right->{$file} } ;
    } else {
	@l_stuff = @{ $left->{$file} };
	@r_stuff = @{ $right->{$file} };
	foreach $r ( @r_stuff )  {
	    if (&is_there($r, @l_stuff) != 1) {
		push @{ $diff{$file}}, $r;
	    }
	}
    }
}

foreach $d (keys %diff) {
    @extract = @{ $diff{$d} };
    print "$d\n   @extract\n";
}

#=========== Some subs
sub is_there () {
    my ($search, @list) = @_;

    for (@list) {
	return 1 if $_ eq $search;
    }
    return 0;
} 

sub open_file () {
    local ($name) = @_;
    open FILE, $name or
        die "Can't open specified file!$name\n";
    my %ret = ();
    
    while () {
        ($key, $value) = split(':', $_);
        push @{ $ret{$key} }, $value;
    }
    return \%ret;
}

CU,
Cos

Java. Quality. Metrics (part 6)

• we're creating a static call graph (CFG) for any given source code, using a commercial or home-grown tools
• having this, we can calculate a few things about this graph, e.g. the frequency of calls to any particular method; the frequency of calls from a method to other methods with-in the code; basic-block based complexity of a code, etc. (currently, we calculate about five or seven of them, i.e. coverage per function, basic block per function, et cetera)
• when executing tests against the instrumented build, we can prepare a code coverage metric for it
• combine these two lists of modules - from CFG and from code coverage runs - by module names
• sort the resulting list ascending by in-call frequency and descending by coverage scores
• let's assume that most frequently called functions are, perhaps, most important from the quality standpoint. Well, their code is called more often, so any problems will immediately affect a top-level or at least quite important functionality.
• if such methods are having low coverage numbers and high complexity or high number of reported bugs, then it might be a good indication that the code has to be targeted by quality engineers and/or developers.

Hidden problems of the blogging

%E2%80%9C

%E2%80%9D

This work is licensed under a Creative Commons License.