The error i was getting…

## A fatal error has been detected by the Java Runtime Environment:##  SIGSEGV (0xb) at pc=0xb53d1635, pid=3933, tid=1804258160## JRE version: 6.0_20-b20# Java VM: OpenJDK Server VM (19.0-b09 mixed mode linux-x86 )# Derivative: IcedTea6 1.9.7# Distribution: Ubuntu 10.10, package 6b20-1.9.7-0ubuntu1# Problematic frame:# J  com.android.dx.rop.code.Rops.ropFor(ILcom/android/dx/rop/type/TypeBearer;Lcom/android/dx/rop/type/TypeList;Lcom/android/dx/rop/cst/Constant;)Lcom/android/dx/rop/code/Rop;## If you would like to submit a bug report, please include# instructions how to reproduce the bug and visit:#   https://bugs.launchpad.net/ubuntu/+source/openjdk-6/#

There is a cut down version of Rational Software Analyzer that is integrated into Rational Application Developer (RAD) 7.5 that allows you to improve code quality and decrease the time it takes to perform a code review. Initially you’ll probably find a fair few items identified, but trust me this reduces as you move forward and start using the analyser as part of your daily routine or even better nightly build. It’ll also help developers start coding to the same standards.

Our development team took the approach that you don’t ‘have’ to fix all the issues identified in a given project/component, but as a rule you should be running the Software Analyzer on the methods and classes you’ve created or edited. So if you edit a method with an issue (e.g missing java doc) it is your duty to correct it. If it’s more complex refactoring we treated on a case by case basis (normally down to experience of the developer). The pros as that all the developers gained more exposure to Java code standard and we were able to tidying some of the older code as we went along rather than a big block of refactoring.

For our first pass analysis I selected the most critical rules plus a few extra around javadoc.  Some might be not be applicable for example there’s a critical rule states you should check a objects type before casting it, a valid rule indeed however all the RAD generated code in the JSF backing beans breaks this rule, so you’ll want to ignore it for classes in the pagecode.* package. Example of RAD generated code that breaks the casting analysis check.

protected HtmlPanelGrid getNewPremiumdetailsbox1() {
if (newPremiumdetailsbox1 == null) {
newPremiumdetailsbox1 = (HtmlPanelGrid) findComponentInRoot(“newPremiumdetailsbox1″);
}
return newPremiumdetailsbox1;
}

The idea is that you Analysed your code before submitted for code review and that if you haven’t fixed the raised issue they should be a comment explaining why. All developers were asked to pay particular attention to the Java Doc rules – can’t really think of an excuse for not adhering to those rules?

My only gripe is that Rational Software Analyzer doesn’t contain explanation of the issue raised? why is not checking an object’s type before casting just an issue? obvious to some but not others.  This enhanced functionality is included in the standalone paid Rational Software Analyzer product. However found a quick google or question on Stackoverflow explains why certain issues have been flagged.

Here’s a few screen shots on how to kick it off:

Firstly go to Run > Analysis

This will launch the Software Analyzer config window, create a new configuration and import the rule set (or select a predefined one)

Here’s the rules with there various priority levels these can be edited. Once your happy click Analyse to start.

This is what you code will look like after the see the blue underlines and ticks and crosses to the left of the code.

Good for beginners.

This is a ideal book for someone starting Java Enterprise Edition (JEE), but also useful for those who want a brief overview of the ne features. It focuses on the changes in version 6 with examples in Glassfish. It also mentioned some of the significant changes in 5 and gives a good high level overview of the JEE platform in general. It also explains things like persistence layer, and ORM.

I’d recommend it to someone who’s new(ish) to java and whats to see what JEE/J2EE is all about. It’s not good as a reference book (but then it’s not pretending to be one.)

System.setProperty(“http.proxySet”, “true”);
System.setProperty(“http.proxyHost”, “130.x.x.x”);
System.setProperty(“http.proxyPort”, “80″);
System.setProperty(“http.proxyUser”, “UsernameHere”);
System.setProperty(“http.Password”, “PAsswordHere”);

Note: This was just a proof of concept to test out consuming a rest webservice, I’m not advocating this as the best way to set the proxy details.

The IBM documentation for the hx:behavior tag is here. But it doesn’t contain examples of how to use it and the describtion of the hx:behavior attributes is unclear in places.

behaviorAction is what you want to do (hide, show, invisible, visible etc)
targetAction requires the ID of the object you want to do the behaviorAction on.

<h:outputText style=“visibility:hidden;” id=“text7″ value=“Initially i’m hidden, “></h:outputText>
<h:outputText style=“visibility:hidden;” id=“text17″ value=“As am I! “></h:outputText>

<h:outputText styleClass=“outputText” id=“text6aa” value=“view hidden text,”>
<hx:behavior id=“behavior4″ event=“onclick” behaviorAction=“visible;visible” targetAction=“text7;text17″> </hx:behavior>

</h:outputText>

Also found that when you specify more than one targetAction you must also specify a behaviorAction for each (which is good if you want to do different behaviorActions to each target.

Note: offically hx:behavior tags aren’t supported in h:outputText, recommended to use outputlink tag.

Info from my Ibm devworks question post

Had this working in JSP ok, and with a slight tweak to account for the : in the hidden field id (fromname:compnonentId) it works.
In JSF file…

function getClientInfo()
{
var clientinfo = “”
clientinfo+=”Browser:” + navigator.appName + “,”
var b_version=navigator.appVersion
clientinfo+=” Version: ” + b_version + “,”
clientinfo+=” Screensize: ” + screen.width +”x” + screen.height
(document.getElementById(’contactfrm:clientinfo’)).value = clientinfo;
}


‹h:form id=”contactfrm” styleClass=”form”>

In Backingbean the usual code to get a request param:

String clientInfo = getFacesContext().getExternalContext().getRequestParameterMap().get(”contactfrm:clientinfo”);


Or is there a better way of doing this? comments most welcome