DefaultMutableTreeNode root = new DefaultMutableTreeNode("Root"); 
DefaultMutableTreeNode child1 = new DefaultMutableTreeNode("Child 1");
root.add(child1);

DefaultMutableTreeNode child2 = new DefaultMutableTreeNode("Child 2");
root.add(child2);

JTree tree = new JTree(root); 
someWindow.add(new JScrollPane(tree));

We could roughly compare the Advanced Research Projects Agency Network (ARPANET) in the beginning of the WWW project without Google Search Engine with the Software Development area without a powerful mechanism to search, mine and retrieve source code samples. Indeed we hadn't 25 billion web pages to index as we did not have all those fancy languages and frameworks in the software development field as we have today.

So, there are several tools available to empower developers with an easy-to-use interface to search for source code snippets and share source code among other developers. For instance, developers can make their source code available to a lot of people through 'forge' repositories, blogs, articles and so on.

In order to classify the evolution of source code search engines, we could say that the First Generation of these tools were the popular Unix command: find (see Listing 2 below). The find command allows the Unix user to process a set of files and/or directories in a file subtree. It can be used to search certain code snippet in a project directory, providing support for coding by "copy-and-paste" or the "develop by example" practice, or you could even call it [reuse].

 
find . –name *.c -exec grep "hashtable" '{}' \; -print

The basic idea is to run the find command on a directory in order to locate a set of files that match a shell pattern or a regular expression. Run 'grep' for each file and look for a certain pattern. Matched lines, including some context, are collected and displayed for visualization. The user may inspect an entire file if he/she wishes.

Analyzing the code search tools evolution, the Second Generation was the traditional search engines which are based on information retrieval technologies. There, the developers could find and retrieve source code samples. Nevertheless, these tools implement techniques such as text relevance and link analysis that can't be integrally applied to source code. So, while the developers are looking for a small source code piece, these tools show plain text as result. Clearly it doesn't apply different concepts and techniques for processing and searching for structured source code, determining the probable intent of a search, leaving to developers the result analysis job. Of course, this type of search has its drawbacks.

Some freshest code search tools (see Table 1 below), and here we could say Third Generation, appreciates the way of thinking to enrich the support and service which will definitely improve the search quality. Currently, the way to automatically retrieve such volumes of source code data is through the use of a focused Web crawler, which is a program that visits many repositories (public source code repositories like java.net and sourceforge) and scans their content, visiting and indexing more source code.

Tool	URL
Google Code Search	http://www.google.com/codesearch
Koders	http://www.koders.com
Ucodit	http://www.ucodit.com/espviewer
Jsourcery	http://jsourcery.com
Krugle	http://www.krugle.com
merobase	http://www.merobase.com

Table 1 – Source code search engines

There are others requirements to take in account while effectively digging for source code, like: Metadata terms, class name, imports, code block, comment block, method return and others. For instance, a Java source code provides a good way to get information to index and crawler, like anotations, code conventions (standard conventions that Sun follows and recommends - java.sun.com/docs/codeconv) and so forth. We can't forget about Fingerprints, which are an interesting feature provided by some Code Search tools. It denotes both the presence and multiplicity of specific programming constructs within individual code entities. Some code search tools make available several ways of fingerprint search, for example, Micro Patterns in Java Code, which provides information as to whether or not simple design patterns are present within a code entity.

The other special feature available in some code source search engine is a kind of binder, where developers can save search results and share them with others, providing benefits not available in traditional search engines. We can imagine an automatic Agent notifying you when additions are made to your binder.

In the last couple of years source code specialized search have been emerged. These tools support different programming languages, and you can filter by license, besides many others interesting features.

When you ask developers the more excited users of source code search engines what is the benefit of using such tools, they point out "reuse", and a lot of them are Java developers. Indeed, this is explained due to the fact that the Java community is accomplished through the process of sharing and reuse.

Another thing that has been emerging is tools for code search directly integrated into the development environment, providing contextually search capabilities where, depending on what the developer is suppose to do on that part of the code, these tools can query a sample repository for code snippets that are relevant to the programming task at hand. For instance, if you are writing a MD5 method within a class, these tools can infer queries from context, so there is no need for the programmer to write queries once the most structurally relevant snippets are returned to the developer and they can be navigated.

Undoubtedly, tools like that can help large organizations to go beyond reuse barriers, empowering them with a straightforward approach for searching, mining and retrieving software components and source code snippets across its, source code repositories (usually distributed). Also, many software developers can quickly find helpful and useful information for building even more high-scale and pluggable software components, keeping them focused on the problem domain at hand.

Last but not least. We hope you enjoyed the reading, and possibly learned a few things. You are also welcome and encouraged to drop your comments here. In the next post, we’re planning to go deeply in the Third Generation source code crawler world, comparing the existing tools, its strengths and weakness, particularly regarding the Java language. ]]> 2006-06-09T00:45:50Z 2006-03-10T18:19:16Z tag:weblogs.java.net,2006:/blog/mayworm/295.4290 2006-03-10T18:19:16Z

Here's How:

• Remember that learning Java platform is a gradual process - it does not happen overnight.
• Define your learning objectives early: What do you want to learn and why?
• Make learning a habit. Try to learn something every day, and put it into practice. You need to type code!
• Remember to make learning a habit! If you study each day for 30 minutes Java will be constantly in your head. If you study once a week, Java will not be as present in your mind.
• Choose your materials well. You can get tips of sites and materials with a JUG near you.
• Find friends to study and practice with. Learning Java together can be very encouraging.
• Move your finger! Practice coding what you are learning. It may seem strange, but it is very effective.
• Be patient with yourself. Remember learning is a process - writing a code well takes time.
• Communicate! There is nothing like communicating. Book exercises are good - having a JUG friend on the other side of the world who understands your code is fantastic!
• Use the Internet. The Internet is the most exciting, unlimited Java resource that anyone could imagine and it is right at your finger tips.

Then I coincidentally came across a blog posted by Okke van ‘t Verlaat which got me thinking about our predicament.

Our J2EE based project demanded that the development of any CRUD follow a bundle of classes defined through several design patterns, as follows:

Diagram

The team made use of this set of classes in about 90% of the use cases they implement. This structure was designed using a Business Delegate, a Session Façade, Application Service(s), Data Transfer Object(s), EntityBean(Simple data Pojo) and Data Access Object. Moreover, it was always necessary to use factory embedded abstract classes for the DAO´s, Business Delegate and Application Service.

The diagram above shows HibernateDAO realizing Interfaces (DAO's). It is important to remind that Hibernate provides database independence for several vendors (in this project we need to be able to work with different databases). As a matter of fact, is it really necessary to create interface for DAO's?

This architecture represents a possible anemic domain model, and it was built from several design patterns that aren’t necessary. There aren't business objects with domain logic, which are responsible to keep track of the business rules. Instead of it, there are services objects that catch the domain problem.

This services objects are using business objects only to storage data. Is it "organized" as procedural design style? They are keeping business operations into service objects in the project as a whole.

I agree that it is important to have a service layer that encapsulates the application logic, helping transaction and managing information of operations. Therefore, does this choice avoid the creation of core business objects? With this architecture, a simple insert required the implementation of several classes. Isn’t it possible to throw some of these classes away?

Why the software architect don't think simple when designing the architecture (KISS - Keep it simple as possible)?

It is fundamental for software architect to provide a solution design that is truly viable and that can be successfully and rapidly constructed, implemented, operated and managed.

]]> 2008-01-02T17:42:16Z 2005-11-22T19:20:37Z tag:weblogs.java.net,2005:/blog/mayworm/295.3682 2005-11-22T19:20:37Z