Category Archives: JavaRanch

how to test a local web application in blackberry simulator

Posted on by
8

Surely there must already be a tutorial on this, but I didn’t see one.  I did see this information scattered amongst various places.  So here it is in one place.

My goal

Make JavaRanch’s JForum implementation more mobile friendly.  It’s not too bad on the iPhone because the iPhone has a better browser.  On the BlackBerry, the forums are much more difficult to use than they need to be.  As a result I plan to starting out by testing a mobile stylesheet with the BlackBerry simulator.  I found an online iPhone simulator.  After the mobile stylesheet looks on the BlackBerry simulator, I can upload it to a test server and try with the iPhone one online.

Note: I didn’t install the BlackBerry Eclipse plugin because I’m not doing BlackBerry development.  If you want the plugin, I did come across a very detailed tutorial.

Steps to bring up app in BlackBerry simulator

  1. From the BlackBerry download site, download both the simulator and the MDS package.  You need the later in order for the simulator to do internet.  If you have a slow connection, note that both are large downloads.  The simulator is 82 MB and the MDS is 45 MB.  (Note to RIM: if one is already running Tomcat, it would be nice to distribute this as a web app.  Smaller download, no need to change to port and less of a memory hog.)
  2. If you are already using port 8080 (such as to run your own Tomcat server.) Open the file “..\Research In Motion\BlackBerry Email and MDS Services Simulators 4.1.2\MDS\config\rimpublic.property” and change the “WebServer.listen.port” property from 8080 to 8081.  Thank you BlackBerry message board for this tip.
  3. Launch the MDS
  4. Launch the BlackBerry Simulator
  5. Launch your local Tomcat
  6. Test away.  Note that you must use your computer name rather than localhost.  (On windows this is the %COMPUTERNAME% property.)  Thanks to ASP forum for this tip.

Actually using the simulator

Some impressions of using the simulator:

  • It defaults to “100%” view.  100% of what?  No BlackBerry is that big!  On a 1024×768 resolution, the screen and keys don’t both fit on the screen.  I immediately switched to 50% view which is about an inch longer than an actual BlackBerry.
  • Luckily the keyboard works without having to click on the simulated device keyboard.
  • All the buttons have a real keyboard shortcut which you can see when mousing over the simulated key.  This helps with frequent operations.
  • To use the scroll wheel, you have to click and drag.  I would have expected mouse gestures to work here because they are more similar to what you do on the device.  Luckily there is a keyboard shortcut for this (hold F9 and use arrows to your heart’s content.)
  • It grays out if you don’t use it for a few minutes.  As does the real BlackBerry.  This is a bit annoying when testing though.
  • Luckily you can paste in from the real system clipboard – useful for testing URLS

Now that I’ve gotten used to the simulator, the site is just as hard to use on the simulator as it is on a real BlackBerry.  Perfect!  That means it suits my needs.

Problems/error messages I encountered

Since most people look for a “problem/solution”, I’m also listing the surprises in that format.  I know that’s what I was looking for!  I didn’t think I’d need a tutorial on setting up a simple piece of software.

  • BlackBerry simulator hangs when I try to access the internet – check you have installed the MDS, turned it on and you don’t have a port conflict
  • 8080 in use when starting MDS – see step #2 and change the port #
  • 403 error accessing localhost – see step #6 and use the computer name
  • Fledge.exe is using a lot of memory – this is the blackberry simulator itself; not much you can do here

The goal

I saw just how bad things look.  There’s a few more steps before actually making it look better – like getting rid of the table based layout.  But I did make progress with the tool support!

klocwork – a review

Posted on by
2

Since I wrote a review of JTest, I decided to do a review of the other commercial product I tried in the Java static analysis family – Klocwork

Installation

I ran into some trouble installing the trial Eclipse plugin. I saw a zip file to use instead of the update site.  I then unzipped it rather than pointing to it as a local install.   Which appears to work – you see klockwork show up in the Eclipse preferences, but get an error when trying to actually use it.

This gave me the opportunity to deal with their tech support.  Which was very good – they identified the problem correctly and told me to re-install properly.

Trial limitations

The trial limits you to scanning 300 files at a time.  This is perfectly reasonable – I can’t think of a reason you’d need to do more than that to see if you like a product.  I wanted to scan the same files as I had with JTest to compare output.

Since our product has more than 300 files, I thought I would just pick a few packages or classes with known issues.  I then learned they mean you can’t scan a project with more than 300 files rather than that you can’t scan more than 300 files.  Okay.  I used an Eclipse refactoring to move a bunch of packages to another project.  I’m not sure what this accomplished via the limit in the trial.  I was still able to scan everything.

The actual rules
In addition to the common static analysis rules (null ahndling, return values), some more interesting rules jumped out at me.  These include:

  1. Log forging – unvalidated input going into a log allows attacker to influence what logged
  2. If statement always evaluates to true/false – I like this was in the default rule configuration.
  3. Unchecked user input used in SQL query.  – It’s not user  input in our case, but a very good check to get you to manually review the code.

Summary

I also liked the minimizing of false positives.  Aside from my installation difficulties, I was very happy with the experience.

parasoft jtest – a review

Posted on by
Reply

I tried running Parasoft’s JTest against the modified JForum use by JavaRanch.

The first thing I did was run all the static analysis rules and got over 47 thousand hits.  Now this doesn’t mean much as some of the rules are cosmetic things and some directly confict with each other. (Use “*” for imports and don’t use “*” for imports imply every single file with get hit for one of them.  I started running all the rules so I could drill down and see what was out there.

A few of the rules were things that I had already noticed and made me cringe when reading the code.  For example, PostAction as a cyclomatic complexity (branch count) over over 40.  Ten is high.  40 is almost unreadable.

Some of the more interesting ones:

  • Found some duplicate code and string literal duplication.
  • The rules were updated for Java 5 – For example, it found I overwrote toString() but not valueOf() in an enum.
  • security rules for SQL injection
  • I really like “remove commmented out Java code” as this is a pet peeve of mine!
  • I learned that there is a problem with “double checked locking” pattern if you don’t use the volatile keyword.
  • As expected, JTest found unclosed resources, missing static keywords and the like.
  • There’s a bug in Java’s substring implementation that can cause an out of memory error.
  • It didn’t find a specific defect I was hoping to uncover when I downloaded it.  But this was more informative than not – now I know that defect isn’t in the code without having to look through hundreds of classes!

Some of the rules offer a “quick fix” where you can automatically fix the violation through your IDE plugin.  I used this to add {} to single line conditionals in 50 places without effort.

The only complaints I ran into:

  • It’s mostly updated for Java 5, but not completely.  One rule says to using StringBuffer instead of String when concatenting strings (when you should use StringBuilder.)
  • It’s slow – 5 minutes – 11 rules – 519 files.  PMD goes faster.
  • And of course – it’s expensive – but it’s intended for corporate users.  Thank you Parasoft for the trial to use on our non-commercial software!

The breadth of errors JTest can find is amazing.  It doesn’t just save you time manually reviewing code – it tells you about subtle errors you might not know about.