Re: Versioning Java Applications

I would consider using the CRC stuff built into zip since at least 1.1.

I somewhat recently did some looking at junit and thinking that comparing data or files would be something that might useful in future test cases I looked at both crc and md5.

Apologies to those not interested, somewhat long for snippets.

 

 public void testCRC() {
// So much fun, one more time, compare CRC32's of files with zip/trz
//              cat known_bugs
  Runner[] runners;
  String run = new StringBuffer(run4).append(required).toString();
  System.out.println(run);
  runners = parser.parse(toArray(run));
  assertTrue("expected number of runners",runners.length == 1);
  for (int i=0;i<runners.length;i++)
   call.mainByName(runners[i]);
  String oldstr = outbuf.getText();
//              cat testfile
  System.out.println(run5);
  runners = parser.parse(toArray(run5));
  assertTrue("expected number of runners",runners.length == 1);
  for (int i=0;i<runners.length;i++)
   call.mainByName(runners[i]);
  String newstr = outbuf.getText();
  java.util.zip.CRC32 csum = new java.util.zip.CRC32();
  csum.update(oldstr.getBytes());
  long zipoldcrc = csum.getValue();
  csum = new java.util.zip.CRC32();
  csum.update(newstr.getBytes());
  long zipnewcrc = csum.getValue();
  System.out.println("java.util.zip.CRC32: " + zipoldcrc +
   " , " + zipnewcrc);
  assertEquals("zip crc's match",zipoldcrc,zipnewcrc);  
  util.CyclicRedundancyCheck crc32 = new util.CyclicRedundancyCheck();
  crc32.update32(oldstr.getBytes());
  long trzoldcrc = ((long)crc32.result32() & 0x00000000ffffffffL);
  crc32 = new util.CyclicRedundancyCheck();
  crc32.update32(newstr.getBytes());
  long trznewcrc = ((long)crc32.result32() & 0x00000000ffffffffL);
  System.out.println("trz crc32: " + trzoldcrc +
   " , " + trznewcrc);
  assertEquals("trz crc's match",trzoldcrc,trznewcrc);
 }

 

TRZ is some of my own zip stuff that still needs a lot of work at least on Windows (Java 1.5). Here I think these actually are being used on non-zip entry files where they still of course work fine. They could be used as well for comparing data in memory. Enumerating the zip and checking each entry would I think be most on-topic here though.

(outbuf holds redirected console or System.out output for the very curious, runners are a Thread subclass of my application which is sort of a commandline shell so something very roughly like Unix processes).

 

For md5.

 

 public void testMD5() throws java.io.IOException {
//  dig testfile.dmp
// (Test comparing using new MD5 message digest command)
  Runner[] runners;
  System.out.println(run8);
  runners = parser.parse(toArray(run8));
  assertTrue("expected number of runners",runners.length == 1);
  for (int i=0;i<runners.length;i++)
   call.mainByName(runners[i]);
  String olddig = outbuf.getText();
  System.out.println(olddig);
//  dig testcopy.dmp
// (Test comparing using new MD5 message digest command)
  System.out.println(run9);
  runners = parser.parse(toArray(run9));
  assertTrue("expected number of runners",runners.length == 1);
  for (int i=0;i<runners.length;i++)
   call.mainByName(runners[i]);
  String newdig = outbuf.getText();
  System.out.println(newdig);
  assertEquals("digests match",olddig,newdig);
// OK, change one, test that for digest failure and call it a test case for now
  MessageDigest md = null;
  try { md = MessageDigest.getInstance("MD5"); }
  catch (NoSuchAlgorithmException nsae) { nsae.printStackTrace(); return; }
  RandomAccessFile r = new RandomAccessFile("testcopy.dmp","rw");
  r.write("BAD".getBytes(),0,3);
  r.close();
//  dig testfile.dmp
  r = new RandomAccessFile("testcopy.dmp","r");
  byte[] b = new byte[(int)r.length()];
  r.readFully(b);
  r.close();
  System.out.println("overwrote BAD To testcopy, now re-digest");
  newdig = dumpBytes(md.digest(b));
  System.out.println(newdig);
  System.out.println("and assert match as false");
  // assertFalse seems to be our one and only inverse tester
  assertFalse("digests match",olddig.equals(newdig));
 }

 

I chose md5 because md5 hashes of downloads seem sort of common these days. I've read somewhat recently though that they are more successfully attacking md5 hashes with forced collisions and so sort of gathered that for crypto secure purposes sha1 should probably be your preference.

 

Mike Hall          mikehall at spacestar dot net