Workaround (I think) for bizarre array corruption problem on Sun WTK and some SE...

git-svn-id: http://zxing.googlecode.com/svn/trunk@619 59b500cc-1b3d-0410-9834-0bbf25fbcc57

diff --git a/javame/src/com/google/zxing/client/j2me/LCDUIImageMonochromeBitmapSource.java b/javame/src/com/google/zxing/client/j2me/LCDUIImageMonochromeBitmapSource.java
index a5cf546..04d0ca3 100644 (file)
--- a/javame/src/com/google/zxing/client/j2me/LCDUIImageMonochromeBitmapSource.java
+++ b/javame/src/com/google/zxing/client/j2me/LCDUIImageMonochromeBitmapSource.java
@@ -30,7 +30,8 @@ public final class LCDUIImageMonochromeBitmapSource extends BaseMonochromeBitmap
   private final Image image;
   private final int height;
   private final int width;
-  private final int[] rgbRow;
+  // For why this isn't final, see below
+  private int[] rgbRow;
   private final int[] pixelHolder;
   private int cachedRow;
 
@@ -52,8 +53,13 @@ public final class LCDUIImageMonochromeBitmapSource extends BaseMonochromeBitmap
   }
 
   public int getLuminance(int x, int y) {
+
+    // Below, why the check for rgbRow being the right size? it should never change size
+    // or need to be reallocated. But bizarrely we have seen a but on Sun's WTK, and on
+    // some phones, where the array becomes zero-sized somehow. So we keep making sure the
+    // array is OK.
     int pixel;
-    if (cachedRow == y) {
+    if (cachedRow == y && rgbRow.length == width) {
       pixel = rgbRow[x];
     } else {
       image.getRGB(pixelHolder, 0, width, x, y, 1, 1);
@@ -79,6 +85,10 @@ public final class LCDUIImageMonochromeBitmapSource extends BaseMonochromeBitmap
 
   public void cacheRowForLuminance(int y) {
     if (y != cachedRow) {
+      // See explanation above
+      if (rgbRow.length != width) {
+        rgbRow = new int[width];
+      }
       image.getRGB(rgbRow, 0, width, 0, y, width, 1);
       cachedRow = y;
     }