Saturday 31 May 2008

Filipino call center catfight - "I Kell You!"



I hope Jerome got fired. He's famous now anyway. :P

Monday 26 May 2008

Java code to concatenate values from get__ methods of a class dynamically

Ended up discarding this code from a project, but this was a good
exercise to learn a little about Java reflection methods.

This was based on code from HashCodeBuilder in Apache commons-lang,
which can generate hashcodes via reflection - ie,
HashCodeBuilder.reflectionHashCode(this);


/**
* Given an object of type clazz, go through the fields in that
class and concatenate the
* values of all the fields, excluding the ones listed in excludedFields.
* This will only work on bean-type getter methods that 1. do not
have parameters
* and 2. return a String.
* This code does not do any lookup on inherited methods.
* @param object instance where we are getting field values from.
* @param clazz the Class of the object.
* @param builder StringBuilder object to contain our concatenated values.
* @param excludeMethods fields that are not to be included in our builder.
* @throws InvocationTargetException when an error occurs while
calling a method in our object.
*/
public static void concatenateFieldValues(Object object, Class
clazz, StringBuilder builder,
String[]
excludeMethods) throws InvocationTargetException
{

List excludedMethodList = excludeMethods != null ?
Arrays.asList(excludeMethods) : Collections.EMPTY_LIST;

Method[] methods = clazz.getDeclaredMethods();
for (Method method : methods)
{
// only get values from public getter methods that are not
in exclusion list
if ((method.getName().indexOf("get") == 0)
&& !excludedMethodList.contains(method.getName())
&& (Modifier.isPublic(method.getModifiers()))
) {
try {

// this will only deal with bean-type get methods
without params
assert method.getParameterTypes().length == 0;

// TODO - shouldnt we explicitly check and throw
an exception here?
Object fieldValue = method.invoke(object);

if (fieldValue instanceof String) {

builder.append(StringUtils.remove(fieldValue.toString(), ' '));
}
} catch (InvocationTargetException e)
{
throw new InvocationTargetException(e, "Unable to
invoke the method: " + method.getName() +
" from
instance of: " + clazz.getName());
} catch (IllegalAccessException e) {
// this can't happen. Would get a Security exception instead
// throw a runtime exception in case the impossible happens.
throw new InternalError("Unexpected
IllegalAccessException");
}
}
}

}

Friday 23 May 2008

Java generics - assigning a List<C> where type D implements interface D to a variable of List<D> - can't be done - AKA:Type Erasure ARRGH!

Java generics still confuse me.

A work colleague was asking me something about assigning typed lists
and it wasn't working the way
it would work if you were simply dealing with single variables.

Class C implements interface D.

Then we have a list of interface D.

Another class E has a method findAll() which returns a list of type C.

But we can't assign E.findAll() to a list of type D.


List<Comparable> listOne;

listOne.add("String");
listOne.add(new Long(1000));

BUT

listTwo = new ArrayList<Long>();

listTwo.add(new Long(33));

listOne = listTwo;

Error: "Incompatible types, Required List<java.lang.Comparable> Found:
List<java.util.List>"


Hmm... maybe we can cast the list?

listOne = (List<Comparable>) listTwo;

Error: Inconvertible types; cannot cast
'java.util.List<java.lang.Long>' to
'java.util.List<java.lang.Comparable>'

But why?

Maven IDEA plugin generating incorrect references in .ipr file in multi-module project

Is there a bug in the maven IDEA plugin when working with multi-module files?
I normally do most of my command-line work in the Cygwin environment, and
have not experienced this problem on my previous project, which was a
single-module project.


ERROR in parent project file:

- generated this when running mvn idea:idea under cygwin
- trying to open the project file results in error dialog box:
"Cannot load module file
'C:\work\Fads\C:\work\Fads\FeedProcessor\FeedProcessor.iml':
File C:\work\Fads\C:\work\Fads\FeedProcessor\FeedProcessor.iml does not exist.
Would you like to remove the module from the project?"

<modules>
<module fileurl="file://$PROJECT_DIR$/C:/work/FeedsProject/packaging/FeedsProject.iml"
filepath="$PROJECT_DIR$/C:/work/FeedsProject/packaging/FeedsProject.iml"
/>
<module fileurl="file://$PROJECT_DIR$/FadsParent.iml"
filepath="$PROJECT_DIR$/FadsParent.iml" />
<module fileurl="file://$PROJECT_DIR$/C:/work/FeedsProject/FeedProcessor/FeedProcessor.iml"
filepath="$PROJECT_DIR$/C:/work/FeedsProject/FeedProcessor/FeedProcessor.iml"
/>
<module fileurl="file://$PROJECT_DIR$/C:/work/FeedsProject/FileService/FileService.iml"
filepath="$PROJECT_DIR$/C:/work/FeedsProject/FileService/FileService.iml"
/>
</modules>

- the fix is to generate the IDEA project file under DOS - mvn idea:idea
- this file is correct.

<modules>
<module fileurl="file://$PROJECT_DIR$/packaging/FeedsProject.iml"
filepath="$PROJECT_DIR$/packaging/FeedsProject.iml" />
<module fileurl="file://$PROJECT_DIR$/FadsParent.iml"
filepath="$PROJECT_DIR$/FadsParent.iml" />
<module fileurl="file://$PROJECT_DIR$/FeedProcessor/FeedProcessor.iml"
filepath="$PROJECT_DIR$/FeedProcessor/FeedProcessor.iml" />
<module fileurl="file://$PROJECT_DIR$/FileService/FileService.iml"
filepath="$PROJECT_DIR$/FileService/FileService.iml" />
</modules>

Saturday 3 May 2008

OutOfMemory error when using Findbugs plugin in Maven? Set the Maven heap size via MAVEN_OPTS

I was doing a "mvn site" and I got an OutOfMemory error at the stage
where it's using the Findbugs plugin:

[INFO] Generating "FindBugs Report" report.
[INFO] No effort provided, using default effort.
[INFO] Using FindBugs Version: 1.2.0
[INFO] No threshold provided, using default threshold.
[INFO] Debugging is Off
[INFO] No bug include filter.
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Java heap space
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
at edu.umd.cs.findbugs.ba.vna.ValueNumberFrame.getUpdateableAvailableLoadMap(ValueNumberFrame.java:409)
at edu.umd.cs.findbugs.ba.vna.ValueNumberFrame.copyFrom(ValueNumberFrame.java:285)
at edu.umd.cs.findbugs.ba.FrameDataflowAnalysis.copy(FrameDataflowAnalysis.java:38)
at edu.umd.cs.findbugs.ba.vna.ValueNumberAnalysis.trans

After a bit of research, I set this variable to give enough memory to
Maven, and it fixed the problem. Obviously, change the Xmx value
depending on how much RAM you have to spare.

MAVEN_OPTS="-Xmx1024m -Xms128m -XX:MaxPermSize=512m"

Other posts have mentioned that it's actually setting a MaxPermSize
higher than the default value (32m) that makes the difference. So
let's test it by just setting the first two values:

MAVEN_OPTS="-Xmx1024m -Xms128m"

Actually, it works!

INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 11 seconds


Other people have recommended setting the plugin property
"maven.findbugs.jvmargs" but I have not tried this out yet. Now in my
pom.xml, I currently have:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>1.1.1</version>
</plugin>

Which isn't actually the latest version anymore. Maybe the newest
version of the plugin - 1.2 has fixed it.. Let's change it to:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>1.2</version>
</plugin>

But this time, let's NOT have anything in MAVEN_OPTS. Let's see if the
newer version can do it with the default java settings. Now run mvn
site again.

(Long delay follows). Oh great, more jars to download. WTF? castor?
openejb? xstream? Hardly a build goes by where I don't get yet another
surprise download due to transitive dependencies. Am glad we have
Artifactory set up at work, so only one person has to suffer the
delays of downloading each new jar file.

No dice. OutOfMemoryError again. Let's set our heap to a smaller
figure, compared to before, see if that's enough.

MAVEN_OPTS="-Xmx256m -Xms128m"

Works!

I think this last one can be a safe starting value to use if you ever
run into the OutOfMemory error Findbugs from inside maven. I was
surprised to find out that the default heap is only 32m when JVM is in
client mode, and 64m when in server mode. See here:
http://www.unixville.com/~moazam/stories/2004/05/17/maxpermsizeAndHowItRelatesToTheOverallHeap.html