SonarJ Architecture Review

We have a relatively new developer on our project. He is a seasoned application developer. So you know he gets down into the trenches of our source code. It is funny how he is disturbed about how many things were done wrong in our system. Many of us know about these problems. But we are too busy or too worried about breaking things to fix them.

There is a new version of a solution called SonarJ that could assist with our problems. It analyzes code and detects your application architectures, and identifies things you have done wrong. You can get a clear view of how bad things are with their metric dashboard.

SonarJ goes even further by projecting the impact of refactoring your code. It does this without disrupting your code baseline. The tool can grab code from your IDE or your build project. And if it was not clear from the name, the tool targets code written in the Java programming language.

Event Based

Java has always used event based programming to deal with user interfaces. Initially would generate events and send them to components. The component would information the system whether it processed the event. If so, that was the end of the processing. Otherwise the system would forward the event to another component, and so on until one did process the event.

By the time Java 1.1 was released, event processing had changed. A new delegation model was adopted which implements the observer pattern. Any components interested in an event implement a listener interface. They register with the system to handle the event. This makes the system's job easier. When the event fires, all listeners registered for that event get notified. More than one component can receive and process the event.

If your component's event processing is going to take any real time, you should do the work in a separate worker thread to keep the system responsive for the user.

Abstract Window Toolkit

I have read an intro chapter on the Abstract Window Toolkit (AWT). It is implemented via the "java.awt" package. The package provides a number of graphic user interface components. Examples are buttons, scrollbars, and checkboxes.

Two of the most useful components are the TextField and TextArea. The TextField is a single line of input from the user, while the TextArea is a multiple line edit control.

Checkboxes are components. They can be grouped using a CheckboxGroup class, which itself is not a component.

A LayoutManager interface has been defined to determine how components are placed on a screen. There are 5 different implementations of the LayoutManager provided to you by the AWT.

Let's talk about a few more AWT concepts. A container is an area on the screen which holds other components. A windows is a top level one on the screen that has no menu bar or border. It is used to create popup messages. If the user provides input in a such a window, it is then called a dialog. A frame, on the other hand, is a window that has a title, border, and buttons like maximize/minimize.

The last idea which I shall expound upon later is that of events. The entire AWT system is driven by events. AWT manages these events, and sends them to interested components. For example, an event is generated when the user clicks the mouse button. The AWT catches this, and sends the information to component(s) that had previously requested mouse press events.

Origins of Java

A Java game programming book uses the Abstract Window Toolkit. So I thought I would read up on it a bit. There are some free materials online that cover this older technology. I figure what I learn can also help in my learning of newer GUI frameworks.

The book I read online claims that the AWT is crucial for Java programmers to learn. Initially there were major changes in AWT before it stabilized. Here is a funny thing. Part of the AWT intro explained the origins of the word Java.

Java is actually an island in Indonesia. It is not just any island. A whopping 124 million people live on the island. That is more than half the population of Indonesia. The capital of Java is Jakarta. This explains the naming for the Apache Jakarta project.

Next time I will get into some of the components that the AWT has to offer.

Accessing an Oracle Database

I am using JDBC to access an Oracle database using a Java program. To get up and running quick, I grabbed some code off the web. After importing java.sql.*, the thing compiled fine. However when I ran my program, I got some exceptions.

The first exception was that the class "oracle.jdbc.driver.OracleDriver" was not found. Ooops. Then I found out that this class had been deprecated. Fine. I replaced it with "oracle.jdbc.OracleDriver". That also generated an exception. There was also exceptions when I tried to make a database connection. The were due to there not being a driver. I figured that I needed to solve the root problem before proceeding.

There were a number of web pages that said I needed the JDBC driver installed on my system. I grabbed the "ojdbc14.jar" file and stuck it in a number of lib folders on my machine. No luck. I thought it might be due to the fact that I had a later version of the JRE and JDK. Turns out I needed the jar file in my classpath. Once I did that, the program worked fine. Now I am inserting a lot of database in my database. Maybe later I will post some code snippets.

JDBC Drivers

I am using the JDBC technology to access an Oracle database from a Java program. This technology requires you to use one of its drivers to do the access. There are different categories of drivers you can use to access Oracle.

One driver category is a thin driver. It has its own version of SQL*Net. In other words, you do not also need an Oracle client installed on your machine in addition to the driver. This category of driver is written in the Java programming language itself. There is also an OCI category or driver, that uses Oracle's Oracle Call Interface (OCI). The final category is a KPRB driver used for writing stored procedures and triggers in Java.

Besides the categories of drivers, there are also different levels of drivers. The first type is a bridge, where JDBC makes use of ODBC installed on your machine. ODBC is a generic database access technology. Other types are differentiated by whether the drivers themselves are written in Java, and how the SQL code is translated and sent to the database.

JDBC Data Access

I have been talking about this new project I am working on. There are a lot of URLs that I want to scrape. The first task is to put the list into a database. I have decided to use JDBC to access the database from my Java program.

Java Standard Edition 6 comes with the "java.sql" package. You should import all the classes in that package. JDBC requires a driver to run. You load the driver in your code with a Class.forName.

Any SQL can be sent to the database using JDBC. By default, the objects used to connect to the database automatically commit after each statement. You should use the close method on the connection object to free database resources.

Scanner Comes Through

I have a new project I am hacking on. The goal is to process a huge file of URLs. Then I want to crawl those web sites and extract information to a database. I will provide some more specifics in the future.

The first task at hand was to deal with this huge file. It was 10 gigabytes large. Most text editors could not handle it. I wanted to see if my Java classes could deal with it. So I coded up a UNIX head program. It lists of the first 10 lines from the file.

Bamm. It worked. The Scanner class could read the first 10 lines with ease. The first time it did so there was a small pause. But I could read and process the first 10 lines. It seems to reason I can process the next 10 lines, and so on.

I will keep you posted on the progress of my little project. Next step is to figure out how to do database access with Java. I am thinking JDBC. But there may be better or more interesting technologies to try out.