Java Installer Error 135

So I was having problems installing jdk-8u11.  I kept getting

Error 1335: The cabinet file ss180110.cab required
for this installation is corrupt and cannot be used.

For some reason, which I still don't understand, downloading the installer with Firefox instead of Chrome resulted in the error going away.  Thanks Dox Starz for suggesting this idea in a comment.

Java vs Groovy: Polymorphism

While doing some studying for SCJP, I was tinkering with some stuff in the Groovy console as a way of testing some stuff in Java and I found they actually behave differently.

class Person {
  protected String name
  protected int age
  
  public Person() {
    name = "secret"
    age = -1
  }
}

class John extends Person {
  int favoriteNumber
  
  public John() {
    name = "nobody special"
    age = 0
    favoriteNumber = 7
  }
  
  public String doNothing() {
    return "junk"
  }
}

Person p = new John()
println p.doNothing()

If you do this in Java (splitting the classes out to their own files of course), it won't compile. Java looks at the reference type for available methods, so you will get a NoSuchMethodException. In Groovy, however, it looks at the type of the object, not the type of the reference so the method is found at runtime. And this is probably what you would want, so I can refer to John or Mary as a generic Person, but they still do the things they do in a John or Mary way.

Java vs Groovy: Overriding static methods

The Java equivalent of below will not compile, but in Groovy it works fine. Groovy supports overriding static methods, whereas Java does not.

class Person {
  protected String name
  protected int age
  
  public Person() {
    name = "secret"
    age = -1
  }
  
  public static String doNothing() {
    return "junk"
  }
}

class John extends Person {
  int favoriteNumber
  
  public John() {
    name = "nobody special"
    age = 0
    favoriteNumber = 7
  }
  
  public String doNothing() {
    return "more junk"
  }
}

Person p = new John()
println p.doNothing()

I don't think this would be a problem. You might want each inherited class to have its own (maybe static) version of a method, but for every instance of the class to only have one in memory. If you don't want the children overriding the method, you should just make them final.

Boolean.flip()

Recently I needed a Boolean in a groovy project I was working on to alternate back and forth (for row highlighting with Apache POI). I thought it would be slick to metaclass a flip() method (something I've always thought should be there) into Boolean. It turns out, this is not possible. I browsed the Java source and learned that all primitive wrapper classes are immutable. I'm not completely sure why they did this. My guess is to protect programmers from hurting themselves by mutating objects in a collection and possibly creating unexpected behavior or a race condition.  I could have created my own boolean wrapper class, of course, or use Apache Commons MutabeBoolean. In the end, I decided not to be fancy and just reference a new object like

Boolean foo = false
foo = !foo

But boy, it would have been pretty & nice to have

Boolean foo = true
foo.flip()

Bad GString! Bad! --- Wait, My Bad

I was trying to write a test for a method that inserted some stuff into a StringBuilder that was modified as a GString and was frustrated to find that my stubbed method was never called!

Initially I got mad, blamed Groovy for making my life more difficult with its ridiculous automagical boxing. Then Josh pointed out that StringBuilder is actually a CharSequence. It's not a Groovy thing, I'm just dumb. Fire up your GroovyConsole and observe:

StringBuilder.metaClass.insert = {int arg0, Object arg1 ->
  println "FOOO"
}
StringBuilder.metaClass.insert = {int arg0, String arg1 ->
  println "BARR"
}
StringBuilder.metaClass.insert = {int arg0, CharSequence arg1 ->
  println "I'M HERE!!!"
}

StringBuilder sb = new StringBuilder()
def foo = "ROGER"
def bar = "$foo"
sb.insert 0, bar

The result is "I'M HERE!!!". All I had to do was stub the right method.

If you're experiencing String vs GString issues, like I thought I was, you may find this helpful.

Beware of openStream

Yesterday we discovered a bug where one of our projects hung and had to be CTRL-C'd. The culprit ended up being one line:

URL url = new URL("http://someurl")
InputStream is = url.openStream()//<---this one

The openStream method is actually shorthand for openConnection().getInputStream(). So it returns a newly instantiated URLConnection and calls getInputStream() on that. The problem is, which the API won't tell you (but is visible in the source) is that the default values for connectTimeout and readTimeout are 0. This means, if the connection/read fails, it will continue to try to connect/read forever. While we tested for the connection to be good before we began processing, getting from a URL caused it to hang when the service went down in the middle of processing. The solution was mentioned in this StackOverflow question. The solution lies in not creating the InputStream from URL, but from URLConnection and setting the timeouts:

int timeoutMS = 5000 // 5 secs
try {
  URL url = new URL("http://someurl")
  URLConnection conn = url.openConnection();
  conn.setConnectTimeout(timeoutMs);
  conn.setReadTimeout(timeoutMs);
  InputStream is = conn.getInputStream();
} catch (java.net.UnknownHostException uhe) {
    // something useful here
} catch (java.net.SocketTimeoutException ste) {
    // something useful here
}

Eric has posted about this as well (it was his project we learned this from).

Substition in Java .properties

Though I ended up not using it for a project I'm working on, I was interested in using the java.util.Properties with substituted strings, as can be done in Ant and Maven. I came across this link to XProperties: http://www2.sys-con.com/ITSG/virtualcd/Java/archives/0612/mair/index.html

@version JavaDoc Tags

Another comment that came up in my code review yesterday was why I had an @version 1.0 in my JavaDocs for the class I wrote. My reasoning was that, according to Sun's documentation, the author and version tags are required (though obviously it won't throw a compiler error or anything like that, it may throw an error in Sun's Doc Check tool). This launched a discussion about whether the version tag should indicate revisions in the version control system (in our case svn) or release tags of the software. The practice varies from shop to shop, but my initial reaction (despite Suns' practice) considered tags to be logical, since that would indicate API changes. However, @since I suppose is what really should be used, and a colleague pointed out that changing all the classes to match whatever release is current hides the fact that some classes (particularly abstract data classes) may not have changed at all.

My own conclusion out of this was to use svn keyword substitution to set the tags. I used my favorite svn client, TortoiseSVN, to set the properties. You can either set it as a global setting (which will add the property to new and imported files) or on particular files (need to do for files that already exist). This matches Sun's practice of tying @version to their source control system.

While on the subject of JavaDoc, I was mocked for pointing out a spelling mistake in a JavaDoc comment. In my view, JavaDoc is a special class of comment. Whereas internal comments can contain all the mistakes and profanity you want, JavaDocs are something your client might actually see, and thus should be treated just the same as a mistake like

System.out.println("Pleez enter your name: ");
String name = bufferedReader.readLine();

Am I wrong?
As a quick way of setting Subversion properties for use in Javadoc, I usually create a script with this in it:

for file in $(find ${1}/*/src -maxdepth 10 -name *.java); do if [ -z `svn proplist ${file} | grep -o "svn:keywords"` ]; then svn propset svn:keywords "Author Date Revision Id" ${file}; fi; done

Things I Learned From My First Code Review

Here's some interesting ideas I saw in my first code review at OCLC

instead of setting to a non-null in constructor to prevent null from being returned, check before it is returned by
doing this

public String getSomeString() {
  return (headerTag == null) ? new String() : headerTag;
}

instead of this

String foo = new String();
...
public String getSomeString() {
  return foo;
}

for String concantenation, StringBuffer is faster than String (http://java.sun.com/developer/JDCTechTips/2002/tt0305.html). Unlike Strings, which are immutable, StringBuffers are mutable.

surround your log4j debug log statements in an

if (log.isDebugEnabled()) {
  log.debug("message here")
}

so that the string isn't needlessly constructed (http://logging.apache.org/log4j1.2/faq.html#2.3)

avoid NPEs in comparisons, do:

String foo = "Some_String";
if (foo.equals(someString)) { ... }

instead of:

if (someString.equals("Some_String")) { ... }