I've been tinkering around for a while wrapping the API to OziExplorer in Java, as chronicled both here and on my work blog. I've finally knocked together an application that uses it. OziGeocacheUK integrates information from GeocacheUK.com and Geocaching.com into OziExplorer. OziExplorer is a GPS mapping application and GeocacheUK is a database of geocaches in the UK. Hopefully this post will help google steer anyone who is looking for such a thing towards it ;-)
I use a GPS mapping application called OziExplorer, and just for laughs I started fiddling around with encapsulating the API for the application so that I could use it from Java. Access to the API is via a DLL, which meant delving into the scary world of both JNI and building DLLs on Win32. Whenever I've tried to do this in the past, it always seemed to require loading vast amounts of unwanted crap on my machine so that I got a compiler that worked, arcane spells involving mapfiles, sacrifical slaughter of various wildlife and so much pain in general that I'd always given up in disgust. However, I'm a glutton for punishment so I thought I'd have another crack at it. I couldn't find anything on the web that told you everything you needed to know all in one place, so I thought I'd document it since I'd got it all working.
Entry updated on 08/04/2006
I've made some minor edits to the Ant scripts to make directories etc. configurable. I've also removed the section which talks about copying all your DLLs to a standard location as it isn't needed - the System.loadLibrary() function will look in the same directory as it's JAR file for any native libraries, so it wasn't actually needed.
Continue reading "Smörgåsbord: Building Win32 JNI code using NetBeans and MinGW" »
Tor Norbye has done a writeup on PMD, a tool that looks for common coding errors in your Java source, for example switch statements without default labels or use of the broken double checked locking pattern. It looked interesting, so I installed the plugin into NetBeans and ran it against the source of my Mobile Bollocks MIDlet. As Tor points out, the default set of selected rules is a bit naff in areas, so I followed his recommendation and enabled them all, then started removing the ones I didn't agree with - about 30 in total. PMD is probably the best tool of its type that I have used, however that's not to say it doesn't have a few quirks:
com.bleaklow.bollocks.ui.About [1]: Error while processing com.bleaklow.bollocks.ui.About; net.sourceforge.pmd.ast.ASTAllocationExpressionThis is triggered by code of the form:
public class Foo {
public Foo() {
new Runnable() { public void run() { Foo.this.back(); } };
}
public void back() {
}
}
The trigger seems to be Foo.this.back(), I've logged the problem - see this SourceForge bug.
SimplifyBooleanExpressions rule claims it is for problems like this:
public class Bar {
// can be simplified to
// bar = isFoo();
private boolean bar = (isFoo() == true);
public isFoo() { return false;}
}
which I agree is a bad practice, the problem is that it also flags things like this as being errors:
if (isFoo() == false) {
doSomething();
}
which I actually think is clearer than the alternative:
if (! isFoo()) {
doSomething();
}
That ! is easy to miss, so I think the explicit comparison against false is actually clearer.
return statement or prohibiting single-character variable names for things like array indexes.
AvoidInstansiatingObjectsInLoops rule is trying to warn you about the potential performance problems that can occur if you continually re-instansiate objects inside a loop, for example:
for (i = 0; i < someArray.length; i++) {
String s = "some string";
doStuff(someArray[i], s);
}
the problem is that it complains about common idioms such as this, which are perfectly fine:
for (int i = 0; i < someArray.length; i++) {
if (matchesCondition(someArray[i]) {
matchedThing = new SomeObject(someArray[i]);
break;
}
I guess what it should really be looking for is the instantiation of an object inside a loop that isn't predicated by a conditional statement.
The other problems I have with PMD are more related to missing functionality, and the degree of integration of PMD into NetBeans:
Vector instead of one of the Collection classes - this would be a fair warning under normal circumstances, but J2ME doesn't actually provide anything other than Vector, so it would be useful to disable those rules for J2ME projects.
However, even with these provisos it is a great tool and it did find a couple of genuine bugs in my code which my code reviewer cough Gary cough missed ;-)
A while back, inspired by Veghead's original version of /dev/bollocks for Linux, I wrote a version for Solaris (source code coming shortly!). In turn I used that to drive the TechnoBabble and MissionStatement generators that I blogged about a while ago. As I said in an earlier post, since being made redundant by Sun I've been hacking on Java using NetBeans, and very good it is too. I also stumbled across the NetBeans Mobility Pack wich allows you to develop J2ME applications, i.e Java applications that run on mobile phones. I was casting around for ideas of something to write, and a mobile phone version of /dev/bollocks sprung to mind. I'm therefore proud to present Mobile Bollocks for your delight and delectation. It should work on any Java-enabled phone - if your phone has any Java games on it, it should work. The webpage allows you to download it directly onto the phone if you have working net access on your phone, if not you can still install it if you have the appropriate PC software for your phone. There's also a phone emulator, so you can see what it looks like in your browser. As Veghead so succinctly put it, "Happy strategic planning"!
I wonder if I can get James Gosling to put a copy on his phone ;-)
I stumbled across a rather interesting website that provides benchmarks and test results of the Java implementations on a wide range of phones. Being an ex-benchmark engineer, this rather appealed to me ;-) The results can be found here. You are supposed to be able to download the MIDlet by browsing the WAP page at http://wap.club-java.com/en, but I had problems reading that page. The direct URL of the MIDlet is http://www.club-java.com/TastePhone/TastePhone.jad, and that worked fine for me.
As I said in my last post, I've spent quite a bit of time over the last few days fiddling with Java, and one of the things that bugged me is that the fonts look pretty crappy because they aren't antialiased. The only way to do this in JVM 1.4 and before is to subclass every widget and/or install your own PLAF (Pluggable Look And Feel) - there are a couple of projects which have done this, for example wraplf and smoothmetal. However, as of JRE 1.5, there's a way to do this globally for your application:
System.setProperty("swing.aatext", "true");
Unfortunately this doesn't work inside an applet as writing to a system property is forbidden and you'll get a security exception. You can achieve the same effect by adding -Dswing.aatext=true to the command line. If you want to set this for all applets you load, open up the Java Plugin Manager, go to the Java tab and click on the View button under Java Applet Runtime Settings. In the table, click on the Java Runtime Parameters field for the 1.5 JRE and enter -Dswing.aatext=true as the value, then save and exit. Voila, all your applets will use antialiased fonts.
Since my employer Sun Microsystems informed me that I was being made redundant last month I've been on so-called "gardening leave", and for the first time in a very long time I've had time to do stuff just for the hell of it. I decided I'd take a look at NetBeans, a IDE for Java that I'd heard good things about.
After grabbing the latest JDK, at Gary's suggestion I downloaded a copy of the Open Source NetBeans IDE to have a play. I've never been a particular fan of IDEs, but NetBeans is actually very good. As well as the editor and debugger there's also GUI designer and a load of other bits, and it all works together very well. I particularly like the 'as you go' syntax checking which highlights errors in your code in much the same way as the auto spellchecker works in a word processor - the erroneous code is underlined in red, and if you move the cursor over the line you get a diagnostic message. The editor also support folding, something I first saw years ago in the Occam editor.
The next job was to think of something small but useful to write. Although I've already deployed some anti-blogspam measures on this site, I'm beginning to notice a gradual increase in attacks - inevitably the spammers are getting wise to the more common tricks used to put them off. Some countermeasures such as the "answer this maths question" approach used by blogs.sun.com are trivially circumventable. The most popular and sucessful countermeasure at the moment seems to be to use a captcha, but personally I don't like them as I feel they are intrusive, and despite the hype about them the implementations often have flaws that still leave them open to attack. The problem is that HTTP is a stateless protocol, so each page has to contain enough context to enable the server to verify that the response to the captcha is correct, whether that be a hidden form field, a cookie or whatever. Because of that, any such scheme is vunerable to capture/replay attacks. Even using HTTPS to encrypt the communication channel doesn't protect against the attacker viewing the page and/or cookie source and figuring out the protection mechanism.
I therefore decided that obfustication of the communication between the webserver and browser was probably a reasonable approach, and one way of doing this was to implement comment submission using a Java applet. However MovableType uses HTML forms and HTTP POSTs requests to submit comments, and as I didn't want to rewrite the back-end I had to figure out how to get a Java applet to behave as if it were a HTML form.