Archive for the ‘EN’ Category

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

Posted on October 1st, 2006 in EN | 4 Comments »

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<Entity> hashSet = new HashSet<Entity>();
Set<Entity> arraySet = new CopyOnWriteArraySet<Entity>();
 
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:

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

Now, a simple mutation, changing an entity name:

e.setName(�NewName�);

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

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

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…

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

Visual Studio developers, welcome to Mac OSX :)

Posted on September 28th, 2006 in EN | 2 Comments »

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

Click to view full screenshot

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

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

Bytecode viewer tools: Jclasslib vs Classfile Inspector.

Posted on August 24th, 2006 in EN | 1 Comment »

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:

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.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

«We bee!» aka Visual Basic reloaded

Posted on August 20th, 2006 in EN | No Comments »

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

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

NUnit for Grasshopper

Posted on February 3rd, 2006 in EN | No Comments »

Those who do not invest in reading Grasshopper Beta forum, should notice that we made a port of NUnit tool hosted in Mono repository to Grasshopper.

It’s located at svn://svn.myrealbox.com/source/trunk/mcs/nunit20. Use nunit.java.sln solution file to build it.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

Database connection problems FAQ.

Posted on September 25th, 2005 in EN | No Comments »

New KnowledgeBase article Database Connection Issues, Solutions and Workarounds contains useful tips for solving various database connection problems with Grasshopper.

Hope this fill be helpful also for Race to Linux guys that use Grasshopper to win their xBox.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

A programming language pattern idea.

Posted on July 21st, 2005 in EN | 2 Comments »

How many times have you seen somebodys code that acts like following:

public class ClassA
{
    private string _myPropertyContainer;
 
    public string MyProperty {
        get { return _myPropertyContainer; }
        set {
            doSomething1();
            _myPropertyContainer = value;
        }
    }
}

I guess it was at least more than a couple of times, including the code of your own. And if you ask the programmer: “Why did you choose to access (or even worse, modify) private member instead of property?” � his answer with 99.99% probability will be “I don’t want the code inside the property getter or setter to be involved here. I just want to access/change the private member value.” And if you ask “Don’t you think this is a symptom of bad design”, you’ll get an answer “Not at all, the overall design is perfect, only this one little thing does not suit into it. It’s ok.”

Thus, everybody understand this is one of the worst thing you can do to your code, but everybody continue doing it. Why do you think people do this? No, this is not because they are bad designers. No this is not because they don’t think that writing error-prone and maintainable code is no important. People do this because they can do.

Yes, I meant that. People write code as bad as language and compiler permit them. If the compiler was able to restrict the access to private member _myPropertyContainer from the Method method, the programmer was investigating more time in design and was creating more clean code.

You may think I’m stupid. What does it mean “have no access to private members”? There is no such a thing! Yes, you’re right. There is no such a thing. But I want it.

Let’s illustrate my basic idea:

public class ClassA
{
    public void ClassA(string s) {
        MyProperty.container = s;
    }
 
    public string MyProperty {
     get { return container; }
     set {
           doSomething1();
           container = value;
        }
    }
}

What does this piece of code changes? Note the private member _myPropertyContainer declaration has moved into MyProperty declaration. And I want that from now on _myPropertyContainer will not be visible for any class members except MyProperty.get and MyProperty.set. That is, if someone tries to access _myPropertyContainer from doSomething(), he will receive a compilation error. Thus a feature proposed will prevent a programmer from making a stupid mistakes by accessing a private member instead of the property.

Now lets take look on the paradigm proposed. First, if we want all of our properties to define a private member, we do not need to define this members at all � let compiler to perform this task instead of us.

public class ClassA
{
    public string MyProperty {
        get { return container; }
        set {
            doSomething1();
            container = value;
        }
    }
}

The piece of code above illustrates this approach: if you want to save a value as a private property member, you can use a special value container which corresponds to it. Of course, at the compile time each reference to this value is replaced by reference to actual property private member. If the container value never used inside property code, that means we have a read-only or calculated property. In this case compiler have no reason to generate private property member since it never used.
Sounds good? Yes, but not good enough. Sometimes you really need to access a private member, mostly in constructor when you want to initialize the property the the default value and any access to property set will change the object state (and, in general, the object is not fully initialized yet). So the second point is to enable an access to private property member from constructor, exactly as done for read only members.

public class ClassA
{
    public void ClassA(string s) {
        MyProperty.container = s;
    }
    public string MyProperty {
        get { return container; }
        set {
            doSomething1();
            container = value;
        }
    }
}

Now the picture is complete. MyProperty has a full access to its auto generated private member through container value. No one else from class members has an access to this property except constructor. Constructor accesses a private members by denoting them as MyProperty.container, so there is no ambiguity here.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

The wider your development opportunities, the better you live.

Posted on July 15th, 2005 in EN | No Comments »

The more I’m working with Grasshopper the more I’m falling in love with this technology.
Why? It’s because of freedom of choice:

  • With Microsoft .NET you’re fettered to Windows.
  • With Mono you have a bit more place for maneuver, but still you can’t go further from the currently supported features. Also yes, you can choose your OS, but you always choose from only two: Windows or Linux.
  • With Grasshopper you have a real freedom to choose since any piece of functionality still missing from your code can be fulfilled by choosing from a widest range of existing implementations � all the C#, VB.NET of Java ones. Your code can run on Windows, Linux, Unix or even Mac (also it was never tested before).
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

System.DirectoryServices beta launched

Posted on July 9th, 2005 in EN | 3 Comments »

We’ve launched DirectoryServices beta version, available now for all Mono and Grasshopper developers.

DirectoryServices beta gives you all the ability to interact with LDAP-compliant directory service by browsing, creating and modifying directory entries. The new mechanism for defining default LDAP server is introduced, completed by ability of querying RootDSE server entry.
Beta version still lacks authentication and encryption features as well as some advanced search filtering limitations. In addition, schema information retrieval is not supported yet.

The source code for beta as well as a project and solution files for Visual Studio are available from Mono anonymous SVN repository, namely at
svn://svn.myrealbox.com/source/trunk/mcs/class/System.DirectoryServices revision 46945 and
svn://svn.myrealbox.com/source/trunk/mcs/class/Novell.Directory.Ldap revision 46945.

If you’re too lazy to work with code, and want just to play with beta, you can always download System.DirectoryServices binaries (for Grasshopper only).

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo

Following in Herakles footsteps

Posted on July 6th, 2005 in EN | No Comments »

And next again she [Ekhidna] bore the unspeakable, unmanageable Kerberos, the savage, the bronze-barking dog of Hades, fifty-headed, and powerful, and without pity.

Hesiod, Theogony 310.

This week I’m playing with adding a Kerberos authentication into DirectoryServices. It seems that I’ll need to make some changes in Novell.Directory.Ldap architecture, so both handshaking initialization and response processing will fit into current flow.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • Reddit
  • Scoopeo