Remote Debugging Java Applications

After my previous article about Remote Debugging .NET Applications using Visual Studio 2010, I was curious to see how Remote Debugging works for Java Applications. This blog post covers Remote Debugging Java Applications using NetBeans 7.0.

The basic concepts of Remote Debugging are the same for .NET and Java but the process of setting up the host and remote computers varies between Visual Studio and NetBeans. Similar to the .NET application used in the previous post, the screen shots correspond to a simple Java application which would popup a MessageDialog on a button click. Get the code here.

Before configuring the host and remote computers, it is vital to understand the Java Platform Debugger Architecture (JPDA). JPDA provides the infrastructure you need to build end-user debugger applications for the Java Platform. It includes the following APIs broken into three layers -

• Java Debug Interface (JDI), a high-level Java programming language interface including support for remote debugging
• Java Debug Wire Protocol (JDWP), which defines the format of information and requests transferred between the process being debugged and the debugger front end
• JVM Tools Interface (JVM TI), which is a low-level native interface that defines the services a JVM provides for tools such debuggers and profilers

Configuring the Remote Computer

Run the Java application using the -Xdebug and -Xrunjdwp options from the command line.

java -Xdebug -Xrunjdwp:transport=dt_socket,address=6000,server=y -jar RemoteDebugging.jar

Here's a description of the options of the java command -

Option	Description
-Xdebug	Enables debugging support in the VM
-Xrunjdwp	Loads in-process debugging libraries and specifies the kind of connection to be made

The -Xrunjdwp option has several sub options. Here are the descriptions of the ones that are used above -

Option	Description
transport	Name of the transport to user in connecting to debugger application
address	Transport address for the connection If server=n, attempt to attach to debugger application at this address If server=y, listen for a connection at this address
server	If y, listen for a debugger application to attach If n, attach to the debugger application at the specified address

By default the application starts in suspended mode. In suspended mode the application waits for a debugger to attach itself to the server at the specified port before the application starts.

Configuring the Host Computer

The host computer is the system running NetBeans 7.0. Open the code of the application in NetBeans and select "Attach Debugger". Specify the Connector as SocketAttach, the Host as the hostname of the remote system and the Transport and Port as specified above.

Specify the breakpoints in the code and they would hit appropriately. There are two major bottlenecks in Remote Debugging -

• The code from which the executable was built should be available at the time of debugging
• Applications cannot be configured for Remote Debugging at runtime. The -Xdebug option must be specified at the instantiation of the application, making debugging live production code difficult

Before I conclude, here's an article from OTN (Oracle Technology Network) on the Java Platform Debugger Architecture. Visit it if you would like a deeper insight into Java Debugging. The schematic of the JPDA is from a weblog, check it out here.

Remote Debugging .NET Applications

From the past few days I have been stuck in resolving a bug which cropped up in one of my applications after it went to Production. The worst part was that it was a machine-specific issue and we couldn't reproduce it in any of our development systems. While trying to find a solution for this, I came across the concept of Remote Debugging.

Remote debugging is debugging a remotely running application through a development environment running on a system other than the one running the app. This is done by connecting the remote system to the system containing the development environment (in turn the debugger) through Sockets. Theoretically this is achieved in two steps -

• The remote computer would open a socket and listen to debug instructions through it. These instructions are feed to the application that is being debugged and the application responds appropriately
• The debugger would connect to the socket opened by the remote system and send instructions through it

Remote debugging can be used in many live situations. Examples include -

• Debugging a machine specific issue which can't be reproduced on systems running the development environment (my exact requirement :))
• Debugging applications which can run only on the server machine due to dependent third party libraries that cannot be used in the development machine

In this blog post, I will be focusing on Remote Debugging .NET applications through Visual Studio 2010. The screen shots correspond to a simple .NET application which would popup a MessageBox on a button click. Get the code here.

Configuring the Host Computer

The host computer is the computer containing the development environment. This is the system running Visual Studio 2010. To enable Remote Debugging, make sure the following ports are open on the host computer -

Ports	Protocol	Description
135	TCP	Required
500, 4500	UDP	Required if your domain policy requires network communication to be performed through IPSec

IPSec (Internet Protocol Security) is a protocol suite for securing IP communications authenticating and encrypting each IP packet of a communication session. Read more about IPSec here. However I am not going cover IPSec in this post.

You can check if the ports are open by using the telnet command at command prompt (telnet isn't installed by default on Windows 7. Install it from the "Turn Windows features on or off" section in the Control Panel).

Configuring the Remote Computer

To configure the remote system for debugging, either download and install the Microsoft Visual Studio 2010 Remote Debugger or copy the folder Remote Debugger from the Visual Studio install path, which is typically C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE. The Remote Debugger is available for three configurations - x86, x64 and ia64.

Visual Studio takes the .pdb files for debugging from the remote system for managed code. So copy the .pdb from the bin/Debug folder of the project to the remote system. Put this folder on share so that Visual Studio can access it later.

To enable Remote Debugging, make sure the following ports are open on the host computer -

Ports	Protocol	Description
135, 139, 445	TCP	Required
137, 138	UDP	Required
500, 4500	UDP	Required if your domain policy requires network communication to be performed through IPSec
80	TCP	Required for Web Server debugging

That's it; both the host and remote computers are up and ready for Remote Debugging.

Start the application on the remote system if it isn't running already. Also start the Visual Studio Remote Debugging Monitor on the remote system using the msvsmon.exe from the appropriate configuration folder in the Remote Debugger directory (The screenshot uses the x86 version).

Open the code in Visual Studio on the host system and select "Attach to Process". Typically Visual Studio identifies the .pdb file of the remote system if it can. If it doesn't, open the Modules screen from Debug -> Windows -> Modules. Check the Symbol Status of the .exe file which is being debugged and if it shows "Cannot find or open the PDB file" right-click on it and select "Load Symbols From" and specific the share path through the "Symbol Path".

Specify the breakpoints in the code and they would hit appropriately. There are two major bottlenecks in Remote Debugging -

• The code from which the executable was built should be available at the time of debugging
• The above mentioned ports should be open for debugging. Most of the developers wouldn't have administrative privileges on the client systems, so they would require people with sufficient privileges to open up these ports. However several organizations wouldn't prefer opening up ports for incoming connections

Before I conclude, here's an article from MSDN on how to Set Up Remote Debugging. Visit it if you would like a deeper insight into Remote Debugging.

TVPs Vs XML - An Analysis Through .NET

A common requirement of .NET applications that connect to databases like SQL Server is passing Lists and Arrays to the database server. Since most of these databases are relational, transferring these Lists of Objects isn't really straight-forward.

One way of passing these objects would be to send individual properties of these Objects to the database server, one object at a time. Obviously this is highly inefficient. Understanding this, various database management systems have provided various approaches to achieve this.

There are two ways of passing such content to SQL Server -

1. Generating an XML from the List and passing it as a parameter
2. Creating a Data Table from the List and passing it as a Table Valued Parameter

Passing Lists and Arrays as XML to SQL Server has been a common approach since SQL Server 2000. From SQL Server 2008, Microsoft introduced a new way of passing Lists and Arrays - Table Valued Parameters.

In this post, I will be evaluating the performance statistics of XML and TVP though a .NET application. I will be doing this through the RetrieveStatistics method of the SqlConnection class. This method retrieves the statistics of an operation through an IDictionary which contains various performance metrics.

This happens only when the StatisticsEnabled property is set to true before executing the query/stored procedure. These metrics can be reset using the ResetStatistics method of the SqlConnection class. Here's a typical usage of this method -

The dictionary contains several provider statistics. There are 18 values that can be obtained from the Microsoft SQL Server provider. A detailed analysis of the metrics that can be obtained from the dictionary is available here - http://msdn.microsoft.com/en-us/library/7h2ahss8(v=vs.80).aspx.

The .NET application that is being used in this post to compare the performance of TVP and XML captures these 18 metrics into an object. However the final analysis focuses on three of these properties - Execution Time, Bytes Sent and Bytes Received.

The application primarily inserts records into a table. The number of records and the value of the records are decided by the application. To understand the effect of load, the numbers of records are raised from 25 to 2500 in gradual steps of 25. For an accurate measurement each step is repeated for 25 times and an average of the metrics obtained is considered.

Here are the graphs obtained for Execution Time, Bytes Sent and Bytes Received -

Execution Time (Records on X-Axis and Time on Y-Axis)

Bytes Sent (Records on X-Axis and Bytes on Y-Axis)

Note - The Bytes Sent for OpenXML and Nodes are almost the same.

Sent Received (Records on X-Axis and Bytes on Y-Axis)

Note - The Bytes Received for TVP and Nodes are the same.

The observations that I could conclude are as follows -

• The execution time for TVP is less than XML (Using OpenXML took more time than Nodes). The execution time of OpenXML was far higher than TVP
• The bytes sent for XML was higher than for TVP. This is probably due to the XML tags that had to be added for the transfer
• The bytes received in all the three cases were constant irrespective to the bytes sent. Though the number of bytes received for TVP and Nodes was the same, the number of bytes for OpenXML was slightly higher. This might be due to the procedure calls of sp_xml_preparedocument and sp_xml_removedocument

On a whole, TVPs look more promising than XML. However this was a very preliminary test and the actual results might vary in live environments.

The SQL scripts and the Visual Studio project used in this post can be found here and the raw numbers are here.

Compiling Visual Basic, C# & F# Code Into A Single DLL Using msbuild

Recently I had a requirement in which a C# file had to be included in a VB.Net project. I knew I couldn't add the file directly to the project, so I cut over the C# file to VB.Net. At first this seemed pretty obvious since Visual Studio maps every project to a programming language and uses an appropriate compiler to compile the files in the project.

But giving it a deeper thought, I felt something didn't fit the picture. Every project, rather every file that we compile using the .NET Framework generates Common Intermediate Language which is used by the Common Language Runtime. It is because of this CIL that we have language interoperability in .NET. So theoretically speaking, code written in different languages should be able to exist in a single assembly.

Though I couldn't find a way to directly add a C# file into a VB.Net project, I found a way to create a DLL from compiled VB.Net and C# code through a concept of the .NET framework called Multi Module Assemblies.

In .NET, the minimum unit of deployment is an assembly; Dynamic Link Libraries (DLLs), Executables (.exe), etc. are all assemblies. An assembly can contain multiple files like resource files, the manifest, etc. It can contain files of another type called netmodules. A netmodule is a unit of compilation. It cannot be deployed directly but can be linked into an assembly. netmodules written in different .NET languages can be linked into a single assembly.

Unfortunately Visual Studio wasn't built for Multi Module Assemblies, hence there's no way to create a netmodule from a project in Visual Studio. However msbuild allows us to create a netmodule from the projects. There are typically three changes that have to be done to the .proj files (.fsproj, .vbproj, .csproj, etc.) for msbuild to generate a netmodule -

1. Changing the OutputType to Module. Visual Studio doesn't recognize this output type, so even when you change this in the .proj files, Visual Studio won't be able to show it in the Project Properties
2. Exclude the AssemblyInfo file from the project. netmodules aren't supposed to have an application manifest. If they do, the linker won't be able to resolve which application manifest should be used when we are building an assembly from multiple netmodules
3. If one netmodule is dependent on another netmodule, a reference to the dependent module should be specified using the AddModules XML node in the .proj file. Similar to DLLs, netmodules cannot be circularly referenced

Once the .proj file has been modified, the project can be built using msbuild. If the project is a part of a solution, building the solution will create a netmodule for this project - msbuild solution_path

Once the netmodules are created using msbuild, a DLL can be created from them using the Assembly Linker of the .NET framework - al /t:library /out:"path_to_dll" path_to_netmodules

With this we have a DLL which contains all the netmodules bundled into one. To understand this better, let's consider an example - I have three projects, one in F#, VB.Net and in C# under a solution called MultiLanguage.

The .fsproj, .vbproj and .csproj have to be changed as mentioned above. From the netmodules obtained from msbuild, the DLL can be created using the assembly linker.

The sample solution and the build script can be downloaded from here. I automated the .proj changes using Microsoft's Build Engine API. You can give it a try here; it takes the .sln file as an input and modifies all the projects in the solution to generated netmodules.

Windows Phone 7 - Hello World!

Ever since Nokia announced its partnership with Microsoft and made Windows Phone 7 its primary smartphone operating system, I anxiously wanted to give it a spin. So in this post, I am going to start by setting up a development environment for Windows Phone 7 followed by a simple Hello World example.

Windows Phone 7 is primarily a successor of the Windows Mobile Platform (the last one in the line being Windows Mobile 6.5). It's a major revamp in Microsoft's Mobile strategy in terms of its application development model.

Windows Phone 7 no longer supports unmanaged code (Win32 and C++ are gone). It is purely built on Managed Code covering Silverlight, XNA and the .NET Framework (Programming Languages include C# and VB.Net). Here's a nice article on Windows Phone 7 application development model - http://blogs.msdn.com/b/abhinaba/archive/2010/03/13/windows-phone-7-series-programming-model.aspx.

To get started with Windows Phone 7 development, download the Windows Phone Developer Tools RTW (Release To Web). It includes the following tools -

1. Visual Studio 2010 Express for Windows Phone
2. Windows Phone Emulator Resources
3. Silverlight 4 Tools for Visual Studio
4. XNA Game Studio 4.0
5. Microsoft Expression Blend for Windows Phone

If you are already using a higher version of Visual Studio or Expression Studio, this toolkit will install extensions to the existing IDEs. The release is also available as an .iso image. Though the Windows Phone 7 toolkit comes equipped with Expression Blend, for most of the basic applications the design mode of Visual Studio should be sufficient.

To get a hands-on experience with Windows Phone 7, let's take a simple application which accepts a username and greets him/her in the next page. The best part of Windows Phone 7 development is that it is pretty much in the lines of other Visual Studio project types we are familiar with like the Windows Forms Applications, WPF Applications and ASP.Net Applications where in the UI can be created easily using the designer and the business logic is maintained in a code beside event driven model in another .cs or .vb file depending on the programming language.

As already mentioned, Windows Phone 7 is built on Silverlight and thereby every screen has a corresponding XAML (eXtensible Markup Language) page, each having its own code file. Movement between these XAML pages is made possible through an instance of a NavigationService class for every page.

There are three important methods provided by NavigationService - Navigate, GoForward and GoBack. Navigate takes a Uri instance specifying the URI location and loads the XAML page specified.

NavigationService.Navigate(new Uri("/NamePage.xaml", UriKind.Relative));

GoBack and GoForward loads the previous and next pages respectively.

NavigationService.GoBack();
NavigationService..GoForward();

Parameters can be passed across XAML pages by appending them to the URL and retrieving them using the QueryString property of the NavigationContext object. This concept of Windows Phone 7 was very surprising. Since Mobile Applications are very similar to Windows Applications, passing parameters through URLs like Web Applications looked a bit off-track.

NavigationService.Navigate(new Uri("/NamePage.xaml?name=" + name, UriKind.Relative));
string name = NavigationContext.QueryString["name"];

Download the example code here.

Introducing ADO.NET Entity Framework

This is the third and final part of my ORM series in which I am going to introduce the ADO.NET Entity Framework, an in-built Object Relational Mapping model of the .NET Framework.

Similar to the previous post, this one also covers the same four principles -

• Configuring a .NET project for the ADO.NET Entity Framework
• Inserting data from Objects directly
• Retrieving data using Object Lists an LINQ
• Changing the Database Management System

Though the screen-shots and the example codes emphasize on C#, the principles are same for all the .NET languages.

Requirements to run the example in this article - Visual C# Express, SQL Server Express and MySQL. Download Visual C# Express here, SQL Server Express here and MySQL here.

Configuring a .NET project for the ADO.NET Entity Framework

To configure a .NET project to work with the ADO.NET Entity Framework, an Entity Data Model is added to the project. The Entity Data Model is primarily a schematic representation of the database tables stored as a XML file. Each of these tables is converted into a class and foreign key relationships between these tables are maintained as Lists inside the objects.

Visual Studio provides a Wizard to create Entity Data Models. Right click on the project and select New Item from the Add menu. Choose the ADO.NET Entity Data Model template from the chooser. There are two approaches available to build the Entity Data Model - Database First Approach and the Model First Approach.

In the Database First Approach, the Entity Data Model is generated from existing table structures. The wizard allows the developer to setup a connection by providing the Database Server name and the Database name. The wizard also allows developers to choose tables, views and stored procedure that are to be a part of the Entity Data Model.

In the Model First Approach, the Entity Data Model is created from scratch and the database tables are generated based on this model.

Once the wizard completes, a designer opens up which shows a schematic representation of the generated .edmx file. This file contains the table mappings as a XML along with a code behind file with a .Designder.cs extension for the auto-generated classes corresponding to the tables. However a drawback with the Entity Data Model is that it combines all the classes into a single file which makes manual maintainence a little difficult.

I used the Database First approach to create the sample application to insert and retrieve data. You can get the MySQL and SQL Server scripts along with the Visual Studio solution here.

Inserting data from Objects directly

The Entity Model generates a class which inherits from ObjectContext. This class acts as a data manager to connect to the Database Management System to retrieve, insert, update and delete records.

ADO.NET Entity Framework maintains the records of the table as a List of objects. To insert new records into the table, create new objects, add them to the appropriate lists and then save the changes using a ObjectContext instance. The following piece of code shows how objects can be persisted -

using (Context context = new Context())
{
// Create the object
context.Objects.Add(object);
context.SaveChanges();
}

ADO.NET Entity Framework does a wonderful job while storing objects with foreign key dependencies. These dependencies are maintained using lists as objects and while storing these records, the appropriate identity keys are inserted into the child tables. However this feature is limited to a few DBMS like SQL Server.

Retrieving data using LINQ and Object Lists

The ADO.NET Entity Framework retrieves data from the back-end tables in the form of object lists. So accessing records is as simple as iterating through these lists.

using (Context context = new Context())
{
foreach (Object object in context.Objects)
// use the object appropriately
}

Since data retrieval is in the form of lists, developers can piggy-back on an other .NET framework feature - LINQ (Language Integrated Query). LINQ makes conditional querying of data a lot easier.

using (Context context = new Context())
{
var objects = from object in context.Objects where "condition" select object;
// use the objects
}

Changing the Database Management System

Before changing the DBMS of the Entity Model, it is important to understand how the ADO.NET Entity Framework stores the connection strings and the mapping between classes and the back-end tables. The connection string is stored in the App.Config file of the project and the table mappings are stored as a XML in the form of the .edmx file as mentioned earlier.

Unfortunately the ADO.NET Entity Framework varies it's implementation with the DBMS. Because of this modifying the XML manually isn't easy. For Example, ADO.NET Entity Framework does not support foreign key constraints in the form of lists for DBMS like MySQL.

The sample application contains another Entity Model which connects to a MySQL Server containing similar tables. To use MySQL with the ADO.NET Entity Framework, an connector is needed. The MySQL Connector/NET is available here.

Introducing Hibernate In Java Using NetBeans

In one of my recent posts, I introduced the theoretical topic of Object-Relational Mapping (ORM) - http://gautam-m.blogspot.com/2010/11/object-relation-mapping.html. In this post I am going to take a step forward and introduce Hibernate - an open source Java persistence framework from JBoss.

This post covers four basic principles of Hibernate -

• Configuring a Java project for Hibernate
• Inserting data using Object Persistence
• Retrieving data using Hibernate Query Language (HQL)
• Changing the database configuration to connect to another DBMS

Though the post and screen-shots emphasize on NetBeans, the concept is the same for all IDEs. Hibernate configuration files can definitely be written without an IDE but make sure all the required class libraries are properly referenced.

Requirements to run the example in the article - NetBeans, MySQL, JavaDB, Java and Hibernate. Java can be downloaded here, installing the All NetBeans package will cover JavaDB and Hibernate. and MySQL can be downloaded here.

Configuring a Java project for Hibernate

The crux of Hibernate is the creation and usage of configuration files. There are three types of configuration files which are to be setup for Hibernate -

1. The .cfg.xml file - this is the main configuration file which contains information about the database like the database URL, the driver, the username and password, etc. Hibernate can optimize it's behavior depending on the DBMS being used. To facilitate this, a property called Dialect is specified. However this is an optional property as Hibernate can deduce this depending on the JDBC metadata returned by the driver
2. The .reveng.xml file - this file holds the data corresponding to the schemas and tables being utilized by Hibernate in the application
3. The .hbm.xml - these files maps POJOs (Plain Old Java Objects) to the table schemas of the database

Typically one .cfg.xml and one .reveng.xml exist for a project and one .hbm.xml exists for each table (mapped to a class). The .hbm.xml maps the object properties to the table columns. It is possible to add new properties to the class which have no effect on the backend tables.

To create these files in a NetBeans project, select New File and select the following File Types from the Hibernate category -

1. Hibernate Configuration Wizard
2. Hibernate Reverse Engineering Wizard
3. Hibernate Mapping Files and POJOs from Database

Follow the wizards to complete the configuration setup. I used MySQL and JavaDB as my DBMS to create a sample application to insert and retrieve data. You can get the MySQL and JavaDB scripts along with the NetBeans project here.

Inserting data using Object Persistence

Inserting data is a cake-walk in Hibernate. All that is there to do is to create the object and store the object data in the database tables using the save method of a SessionFactory object. The following piece of code persists the object data -

SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();
Session session = sessionFactory.openSession();

// Create the object
session.save(object);

Retrieving data using Hibernate Query Language (HQL)

Retrieving data is done through a query language designed for Hibernate called the Hibernate Query Language. HQL is a Object-Oriented Query Language and is very much similar to the traditional SQL we use. The beauty of HQL is that the result of the query is returned as a list of objects rather than as a ResultSet. These objects can be used directly in the code without any overheads. HQL is very wide topic, so I am going to skip the details here but there are several tutorials available for HQL on the Internet. The createQuery method of the above Session object is used along with the list method of the Query object to get the objects -

Query query = session.createQuery(queryString);
for (Object object : query.list()) {
// cast and use the object appropriately
}

Changing the database configuration to connect to another DBMS

The best feature of Hibernate according to me is it's ability to change a DBMS without any change to the application code. To change the DBMS, open the Hibernate Configuration File (typically hibernate.cfg.xml) and change the dialect, driver class, connection URL, username and password to the values corresponding to the new DBMS.

These changes can be done either through the design view or directly on the XML.

Capital IQ - Moving To McGraw Hill Financials

In a move to foster innovation and drive growth, The McGraw Hill Companies (NYSE: MHP) announced several Organizational and Management changes a few days back (November 15th 2010).

Though there are a few Management changes, I will be mostly stressing on the Organizational changes here. From a bird's-eye view, the current financial services of McGraw-Hill will be realigned into two segments - Standard & Poor's and McGraw-Hill Financials.

Currently, McGraw-Hill Companies is divided into three segments -

1. Financial Services which includes Standard & Poor's Credit Market Services and S&P Investment Services (which includes Capital IQ)
2. McGraw-Hill Education
3. Information & Media

Beginning January 1st, 2011, McGraw-Hill Companies' reporting segments will be -

1. Standard & Poor's - the leading credit rating company
2. McGraw-Hill Financials - combining Capital IQ (including ClariFI, Compustat, etc.), S&P Indices, Valuation & Risk Strategies and Equity Research Services
3. McGraw-Hill Education - the world's premier education services company
4. McGraw-Hill Information & Media - a global business information company

The words of Harold McGraw Hill III, President and CEO of the McGraw Hill Companies on the strategic decision -

"This change will enhance our ability to deliver a broad and deep suite of products for investors across asset classes around the world, positioning us to capitalize on the growth trends we see in the global financial markets."

Check out the official announcement here. Coming to the impact of this decision on the Capital IQ brand - I guess our tagline "A Standard & Poor's Business" might change accordingly. However, there hasn't been any official confirmation on this. I will post in an update if we have anything.

RockMelt - Will Melt Your Heart

In my previous post I said I would be writing about Hibernate in this article, however I made an exception to write about a new browser I just started using - RockMelt. RockMelt is a social media web browser developed by Tim Howes and Eric Vishria and backed by Netscape founder Marc Andreessen.

It wouldn't be an overstatement if I say that it will melt your heart, especially if you're into social networking and particular a regular Facebook user like me. Here's how RockMelt looks like -

By this time, I guess most of you must have realized that it looks pretty much like Google Chrome. In fact it is more-or-less Chrome itself. Developers who have been interested in Google Chrome would have heard about Google's Chromium project - the open source project from which Chrome was born. Chromium was the parent of browsers like Nickel and now RockMelt.

However RockMelt was built to target a specific crowd - the Social Networking generation, especially users of Facebook and Twitter. Let me highlight a few features of RockMelt which I found interesting -

Friends Strip

RockMelt integrated Facebook's chat application directly into the browser as a strip running in the left side. The chat UI is pretty impressive; in fact it is as good as Google Talk. The best part is that each chat window now runs as a desktop app independently of the browser allowing users to use chat windows individually like Google Talk.

Status Updates

Updating your status in Facebook is just a click away from any site. With RockMelt, you need not actually go to Facebook to change your status or share a link. The browser itself allows you to do it.

RSS Feeds

The best thing I liked about RockMelt was its integration of RSS/ATOM feeds with the browser itself. Though many browsers manage feeds, nothing can beat this. The integration of the feeds as a strip to the right is really awesome. By default, feeds of Twitter and Facebook are built into the browser. Feeds from other sites like Gmail and Blogs can be added easily.

For people who use browsers only for surfing the web and reading articles, these changes won't be much and the regular Chrome browser should be enough. But people who are into Networking, Blogging, etc. will find it exciting and might enjoy it.

RockMelt was released a few days back and is presently “By Invitation” only and if you are interested, you should register yourselves here for an early access - http://www.rockmelt.com/. Lucky I got an invitation from one of my friends :). So if you want to try it, either register at the mentioned site or catch hold of a friend who already has an invitation :D.

Know more about RockMelt straight from the horse's mouth -

I will back on Hibernate and ADO.NET Entity Framework in my next two posts. Until then Happy Facebooking and Happy Twittering :)