Java Hair

The 11g release of JDeveloper includes a utility to perform code audits without having to install additional plugins. While the information it provides out of the box is minimal, for some violations you can also ask JDeveloper to fix the code automatically.

The metrics it provides:

NOS: Number of Statements in the construct.
V(G): Cyclomatic Complexity, a metric that captures the number of branches that can be taken through a method.
DIT: Depth of Inheritance Tree, this metric describes how far a class is from it’s furthest ancestor, or really, how many classes has it inherited from.

You can run audit reports on your projects pretty easily.
1. Select the project node in the Application Navigator.

Select the Project to Audit

2. Select Run from the main menu bar.

3. Select Audit Project.jpr

4. Choose All Metrics

View Audit Reports in JDeveloper

5. View the report in the log window

You can also run audit reports on rules violations. You can easily modify which rules you would like to include and which you wouldn’t along with which available metrics you’d like to include.

Change the Rules to Audit in JDeveloper

A couple things to keep in mind as you view the metrics:

1. The V(G) of RowImpl classes is going to be high because of the case statement within the getAttrInvokeAccessor method. This is normal for ADF.

2. The DIT is going to be above the default threshold for some of your Impl classes also, for instance, any Application Module Implementation. This is the class you need to extend is already so far down in the chain.

There are only a couple metrics that can be run from the audit tool built into JDeveloper and I’m sure there are ways to integrate other code auditing tools in JDev, but at least it’s a start.

One tool I was hoping to see which I imagine is a long way off is some type of auditing tool for ADF itself.  Since so much of it is declarative and new, no existing tools are going to work on it, but it’d be nice to be able to audit the declaritive part of ADF projects for best practices.

I am going to be at OOW this year, as usual, and this time I will be presenting my talk on using ADF 11g as a platform for Oracle Form conversions.

My presentation outlines the use of 11g ADF Faces, ADF Business Components and JDeveloper as a target platform for applications that were previously written in Oracle Forms. The 11g version of ADF contains many new features that make it a much better framework for such conversions than others. These include the use of Task Flows and richer JSF components. . This presentation explores some of the difficulties in recreating such applications in a web environment and shows how ADF 11g can be used to alleviate some of those difficulties and what difficulties still remain.

I signed up for the Unconference early to reserver a spot, so right now it is scheduled for 11am on Tuesday morning in Overlook I. Hopefully when I get there to sign up, the slot will still be available, stop by the booth before then if you are interested in attending or check the schedule that will be posted there.

If you are going to be there, be sure to stop by!

Be sure to check out the rest of the Unconference Schedule.

Today I ran into an interesting problem. A portion of our software saves the text of database DML statements into an Oracle schema. We had been allocating 4000 bytes of a VARCHAR2 column in order to store that text. We’ve been using this software to analyze customer’s applications for about a year now and hadn’t run into any difficulties with this setup.

Today, while persisting some data about a customer’s form application, our software started to blow up, throw Oracle ORA-01461 errors. The text of the error is “can bind a LONG value only for insert into a LONG column.” At first glance it seemed obvious enough, we were trying to insert a LONG value into a column that wasn’t a LONG column.

The first thing to realize is that a LONG value in Oracle’s database world is NOT a Long value in Java. Since there were about 6 of these types of fields being inserted into a table, that was my first bad assumption, that one of these was wrong. Of course, they all matched up to the columns in the table correctly, but assuming that something strange was going on in the driver, I manually switched these statements to setting BigDecimals instead of long’s. Naturally, this didn’t help at all.

I did turn out to be correct on one count, however. Something strange was happening in the driver. After being puzzled for a bit longer, I called in a developer to help me talk through the problem, and as often happens, just talking about the problem often brings new insight into the situation.

I realized while explaining to this developer that a LONG does not equals a Long, that the problem must lie in the text fields. Duh. So, since I was debugging at that point already, I inspected the values I was trying to insert and realized that one of the text fields was actually pretty large. So large, in fact, that the eclipse debugger couldn’t show me the entire value. It did let me know that the String i was looking at was almost 15,000 characters in length, however.

Aha! So, checking the table structure showed me that the column was set up for VARCHAR2(4000). Apparently, instead of the driver throwing an exception that the value was too large for the column, because the String is over 4000 characters long, it automatically converted it to a LONG datatype and tried to insert that resulting in the ORA-01461 error I was seeing.

To test this theory, I put in some code to check the length of the String and truncate it to 4000 characters if it was longer than that. Voila, no more errors. Of course, I’ll have some work to do to change the column type, probably to a CLOB like the rest of our really long text fields, but that is going to mean changing some code around since CLOBs are not as easily read from the database as VARCHAR2’s are, but at least the problem is isolated.

In my search for information about this error I did not see anything that mentioned this, so I thought I post it to hopefully help some other poor sucker that’s butting his head against his keyboard in frustration due to a similar issue. Hope this helps!

Yep, our blog was subjected to hacking and some of the pages were injected with some “badware” links to some suspicious stuff. Sorry for the inconvenience. I’m also sorry that it took so long to find the offending posts. I cleaned up one post and couldn’t find anything else, but apparently I didn’t look far back enough.

I did a bunch of searching and found this wonderful utility, the Bad Neighborhood Link Checker and unlike Google which just said the site had some suspicious links on it somewhere but didn’t specify where, this told me what page had the suspicious links.

My thanks to Michael VanDeMar for making the tool available online and for free!